Дистрибутив MQX для ColdFire выложен на сайте Freescale

http://www.freescale.com/webapp/sps/site/h...p?code=MQX_HOME

Убийственно маленький футпринт (от 5 Кб).
Убийственно быстрое переключение контекста (от 0.4 мкс).
Убийственная масштабируемость (вплоть до поддержки MMU и межпроцессорных коммуникаций IPC )

Наиболее богатый фреймворк из всех упомянутых конкурентов: TCP/IP стек включающий полнофункциональный PPP, WEB сервер, SNMP, NAT сервис, API туннеля, мультиинтерфейсность с форвардингом и роутингом.

USB стек для хоста EHCI (HID, Hub, Mass, Printer) и дивайса, FAT16, FAT32.

Легкость портирования на другое ядро. Практически такая же как в uC/OS, надо переписать один ассемблерный файл - dispatch.cw

Хорошие сервисы управления памятью, концепция драйверов, гибкий шедулинг, конфигурация в одном .h файле и т.д.

А где список процессоров для которых её портировали?

Хм... интересная штука, честно. Для процев с очень маленьким объемом памяти очень подойдет.

Но первый вопрос, сразу же возникает: лицензия какая??? На сайте вроде нашел, но пока не совсем понятны ньюансы.
Далее: а под что оно портировано уже? Кто портировать будет? Дядя Вася?

Если скачали, может выложите для обозрения?

А вот пусть они её на HCS08 для начала портируют - тогда и посмотрим кто кого.

С маленьким объемом...!?
Вы разве не поняли, что ребята в этом просто прикалываются.
Им реально на 500 MHz монстрах объем до лампочки.

Указанный маленький объем получается у голого шедулера с усеченными сервисами, на практике такое не знаю кому нужно.
Это лишь демонстрация гибкости конфигурации.

Сама соль в фреймворке и особенностях сервисов RTOS в частности IPC который в отличии от той же RTEMS основывается на обычных драйверах IO
Кто понимает в этом толк не станет спрашивать "а где порт?", а молча портирует за неделю.
Ибо это большой прорыв в сторону дешевых мультипроцессорных realtime архитектур.

Тут наткнулся на http://www.thefreelibrary.com/ARC+Announce.....-a0122726673:



Как-то многовато будет $12,500 за убийцу uC/OS ...

Конечно, можно строить свои устройства на ворованом коде, ничего никому не платить, но это не достойно... Лучше на эти $12500 я куплю пару тысяч комплектов Flash+SDRAM и засуну туда линукс + риалтайм расширения

Ну я ж не сказал, что это убийца линукса.
Кто выбрал линукс для глубоко embedded сам себя наказал.

Ну а тем кто не в курсе поясню, что за IPShield-IPSec серьезные клиенты заплатят гораздо больше чем 12e3 $

В предложенном дистрибутиве от IPSec остались только комментарии к сожалению.

Линух куда ни попадя пихать тоже не хорошо. С другой стороны есть куча свободных осей, FreeRTOS к примеру.

Кстати если уж развивать мутную тему лицензий, то у Freescale на MQX она прозрачней и понятней чем на FreeRTOS.

FreeRTOS состоит из кучи чужих кусков в каждом из которых может оказаться какя-нить особенная лицензия.
Там, например, есть лицензия от Луминари и есть лицензия от Дункеля. Некоторые требуют строго предоставлять исходники.

В лицензии на MQX не фигурирует никаких чужих исходников и она не заставляет открывать исходники.
Но! Зато она запрещает реверсинг кода на основе MQX со стороны тех кому вы ее передали или продали.
Freescale только хочет чтоб вы не делали бизнес на его имени и не лепили на свои дивайсы наклейки типа они сделаны с применением технологии Freescale.
Ну и еще операционка должна применяться только с продукцией содержащей программируемые чипы Freescale.
Но как бы нет прямого указания что именно и только чипы Freescale должны содержать операционку.

Т.е. может стоять например i.MX и рядом STM32 и FPGA с NIOS. И все могут содержать MQX.

Хотя MQX интересна и своими фрагментами. Например у них очень неплохой Shell и сервис базы данных имен. Такие вещи не грех и "позаимствовать".

Да и запутанная она добезобразия. И мне лично не нравится. Ну а кому сейчас легко?


Вы в США или где? Оно, конечно не плохо, когда есть техподдержка, когда приходят апдейты, багфиксы итд. Но будем трезво смотреть в глаза, СНГ, + Китай + Корея + ??? глубоко ложили на все эти лицензии, также как и на авторские права итд.


Ну только не нужно никого смешить. Уже давно отмазку придумали что реверсинг допустим для изучения или там чего-то еще, и усё.


А рояли хочет? Кроме того, никто не мешает заплатить фрииРТОСу.


ИМХО, сейчас ось должна содержать кроме шедулера
поддержку файловой системы, TCP/IP не кастрированный, GUI, USB. Может еще и всякие блютулзы. Оно там есть? Насколько стабильно работает?

Я с вами согласен на все 100.
Просто у "убийцы" должно быть все схвачено. Порядок и с лицензией.
Рояли тоже не нужны.

Насчет полноты TCP/IP вопрос не такой простой.
Многое зависит что вы от него хотите и какие планы строите насчет него.
Сейчас TCP быстро спускается вниз до уровня сенсоров и простейших датчиков типа дверных герконов.
TCP/IP мапируют на беспроводные сети типа ZigBee.
Актуальнее встает проблема собственных роутеров и шлюзов для этого хозяйства, администрируемых собственными тулсами c гораздо более гибкими настройками чем у SOHO роутеров типа D-Link.
Здесь важна мультиинтерфейсность стека и маршрутизация
Для гибкого администрирования без разработки специального софта для PC важна поддержка SNMP.
Для разделения одного IP адреса всеми дивайсами в сети нужен NAT сервер.
Для открытия свободного доступа к каждому дивайсу в локальной сети из интернета нужен протокол тунеля.

Все это есть в MQX. А вот во всех названных в заголовке топика осях такого набора нет.

C USB тож понятно. Много чего есть чего нет у других.

С GUI проблема. Его не дали. Но такая же проблема и у других.

Насчет стабильности эт скорее зависит от того как портируете.
Но авторы серьезно подумали о надежности.
В ядро встроен kernel log.
Отдельно есть модуль логов на 16 независимых журналов.
И еще есть механизм скоростных облегченных логов.
Вообщем, баг найти несравнимо легче чем даже в uC/OS

А вариантов не так и много.
Если Ethernet, то это ARP, DHCP, полный tcp/ip (с дефрагментацией, всеми проверками итд), это простенький web сервер (настройки, статистика) итд.

Тут надо UNIX ставить, и не изобретать велосипед.


Маршрутизация есть.
А если она нужна, как и всякие NAT, SSH итд, то как я уже писал, нужно UNIXставить.

Так вот прикиньте, кто-то мается, ставит UNIX по вашему совету.
Покупает для этого какие-то навороченные сомнительные платы с RAM-ом не меньше 16 Мб утешая себя мыслью что это все скоро подешевеет.
Сам то такую плату не сделает какую хочет - умрет BSP переписывать.
Потом долго объясняет клиенту как это настраивается.
Потом еще делает пинговалки для этого монстра. Он же будет виснуть, если не по аппаратной причине, то по программной.
Вычистить то от багов такую махину просто нереально.
В конце концов придется посоветовать клиенту не ставить такой дивайс в ответственные места.
Ну и под конец плюнуть, зайти в эту конфу и начать прославлять Линукс.

А тут конкурент на каком-то LM3S9B90 за 12$ и 512Кб внешнего RAM-а делает и NAT, и SNMP и PPP и RNDIS и т.д.
и управляет всем сетевым embedded хозяйством без всяких рисков.
Он и время на разработку вместе с железом потратит не более 2-х месяцев и продавать будет за смешную цену.
У него кроме низкой себестоимости, будет дешевле сборка, наладка, тестирование, документирование и ремонт.

Скорее думая что скоро 16 будет не купить, и придется покупать 32.


В смысле?


У кучи народу работает.


512 килобайт статики будет дороже чем SDRAM.


А линух даст дикое сокращение сроков разработки чего либо на этой платформе в дальнейшем.

В моем контексте здесь не покупатель думает. Ему тут думать не дадут.


Эт словами не объяснить. Через это надо пройти


Но какой ценой? Здесь важно правильно знать цену.


Я специально не указал тип RAM-а.


Здесь просто не согласен. Это миф.

Хорошо. Где ВЫ будете покупать 512 килобайт памяти, когда минимально доступная будет мегабайт на 8?

А что цена? Купил готовую борду, проверил как работает на ней. Если не работает, то купил у тех у кого работает. Потом обточил как нужно и все.



Сейчас SDRAM контроллеры уже на микроконтроллера во всю применяется. Так что тут тип очевиден. А вот где брать на 512 килобайт, очень не очевидно.


Какой миф? Что проще писать на персоналке а потом просто прокомпиировать на embedded девайсе? Или миф что под линух на ARMе куча софта собирается совершенно спокойно?

7616 позиций RAM от 512 Кб и меньше на Digi-Key устроит?


Так вам и скажут что на борде работает, а что нет. Вам еще R&D добавляется по исследованию плат


Ну кому очевиден тому флаг в руки.
А у нас есть выбор. Очень интересные фичи может дать направление скоростных NVRAM-ов на разных технологиях.



В книге Руссиновича о ядре Windows есть интересная статистика зафиксированных службой тех.поддержки причин краха системы.
Так 80% приходится на драйвера и аппаратуру.
Т.е. для embedded пратически бесполезно что либо запускать и проверять на PC.
И не путайте кучу софта с кучей барахла. Или уж назовите хоть одну такую полезную для embedded позицию из этой кучи.

Оно и на ПЦ-то собирается не у всех и не с первого разу, а уж на АРМах...
У нас один горячий голова тоже сначала руками размахивал, кончилось тем что с помощью админа и какой-то матери установил линух на буке, на том дело и закончилось.
А на АРМе у него теперь работает WinCE

Посмотрел. на 512 килобайт цены начинают от 3.45 бакса
http://search.digikey.com/scripts/DkSearch...ame=706-1057-ND
А вот за 2.9 на 8 мегабайт.
http://search.digikey.com/scripts/DkSearch...e=557-1092-1-ND
А SDRAM на плате это меньше места, меньше проводов итд.


Я куплю борду и посмотрю.


Как даст, так и обсудим.


Та што угодно. Начиная от NTP, FTPсервером, ssh, итд.
Про бесполезно. Это вообще шутка. Я не предпочитаю алгоритмы отлаживать, там, где дебаг максимально удобен.


Если руки из задницы, то тогда да.
У меня линух на буке. С него и пишу к стати.

Я тип памяти не указывал. Это вы с чем-то личным спорите.


Правильно. И не одну купите.


Функциональные эквиваленты этого есть и в MQX правда в полном варианте.
IPSec пожалуй понадежней будет чем ssh (не забываем что ssh это вообще-то зашифрованный SSL-ом телнет и не более)
А найдите-ка стандартный IPSec нахаляву в линуксе.



Дебагить вы будете на самом деле приведения.
80% багов можно словить только на целевой платформе.
Кстати, в нативных кода насколько знаю симулировать ARM-ы могут Keil да IAR. Ну там еще Multi и проч. редкость.
А в PC линуксе будет отладка софта не в нативном бинарном представлении ARM-ов.
Значит еще 10% необнаруженных багов перекочуют на целевую платформу.


Эт не тот линукс.

Вынужден не согласиться. SSH - суть туннель. Через него можно что угодно гонять. Хотите - телнет, хотите - иксы, да что угодно. Я, например, однажды мускуль гонял по нему.

Я указал современный тип памяти. Хотите использовать статику, флаг вам в руки. Могу подсказать где можно купить ПЗУ с УФ стиранием.


Зачем, не подскажите?



Чего именно? kopete есть?


А он уже разве не встроен в ядро?


Вам не приходит в голову что это как минимум от софта зависит?


На РС, я буду отлаживать код в х86. А потом пересоберу под линух.



А, понял. У вас свой, особый, предварительно пропатченый, линух, в который специально добавили кучу глюков? Ну, чтож, удачи,...


И порты можно мапить, и файлы гонять. Но это какая-то там "настройка", которая "не стандартная", хотя у всех давно работает на самых разных компьютерах операионках.

Ладно он еще и тунель. TCP тоже тунель, и IP тоже, и HTTP.
Толку мне от этого тунеля если его мобилы не понимают.

Можно подумать, что IPsec там реализован.

Хотите ssh-клиента на жабе подгоню? Правда, не на всех реализациях стеков в мобилах работают локальные серверные сокеты.

Вспомните контескт обсуждения и может найдете правильные критерии выбора памяти.


Может вам еще медиаплеер в дивайс который в боксы по IP67 закладывают .


В процессорное ядро?



Не..., типичная ошибка новичков.
Проблема качества софта это вообще-то моя любимая тема, поэтому не обсуждаю ее всуе



Какой ценой? Давайте обсуждать цену, а не прецеденты.




Так для тунеля ssh через NAT нужен SOCKS клиент как минимум. И еще найти где нить надежный SOCKS сервер.

А IPSec в смартфонах реализован. Под WinCE точно.

1. Больше,
2. Дешевле.
3. Быстрее?


Значит нет. А как-же ICQ?


Другого вы не знаете сталобыть.


Кто-то из нас явно новичок.


Проц с MMU + SDRAM + NAND.


У меня в роутере линух. NAT там есть. ssh наружу работает. Я что-то делаю не так?


ssh тоже точно работает.

Вы бы курнули чтоли архитектуру SSH http://tools.ietf.org/html/rfc4251. Использование носков - это всего лишь способ динамического указания порта на другой стороне. Возможно и простой туннель, входящий порт на одной машине - исходящий порт на другой машине.

А что вы вообще делаете. Роутеры? Где посмотреть?
ssh в дистрибутиве WinCE не нашел, где вы его там видели.

И что значит ssh наружу, нужно чтоб броузер в дивайс в сети за NAT-ом по HTTP залезал. Залезет?
Думаю без шансов.

Я много чего делаю.


Погугли-те, что-ли.


Только если руки из задницы, и человек никогда NAT не настраивал, и вообще не знает что это такое и как работает.

Если чесно, то не актуально, тут ради одного порта разгребать спецификацию SSH.

Под Win2003 есть пару тысч портов по PPTP, L2TP и PPoE c IPSec-ом в придачу.

Былоб интересно услышать как запихнуть это ssh в собственный дивайс на Cortex-е.


Удивительная скромность


NAT тут не причем. Мы говорим о ситуации когда дивайс стоит за чужим NAT-ом, к примеру NAT-ом провайдера интернета.

На сайте атмела есть пример для avr32, под freertos.


Огласите пожалуйста весь список. у меня видимо с телепатией, не очень.

Ну наконец вы вернулись к FreeRTOS.

Я в начале приводил такую схему когда есть сеть дивайсов из них один роутер с NAT-ом поскольку все делят один внешний IP.
И есть еще NAT провайдера через который надо делать тоннель к NAT-у дивайса-роутера.
У FreeRTOS насколько помню есть только моноинтерфейсные IP стеки поэтому MQX и имеет преимущество.

Слово моноинтерфейсное, очень сложное. А FreeRTOS уж вообще ничего про tcp/ip не знает (вы уж извините за то что я вас немного просвятил). Так что я тут Ваши мысли не сумел прочитать.

Да ничего, я ж понимаю.
Вы просто хотите что-то узнать.

Во FreeRTOS применяют одну из двух адаптированных под эту ось вариаций стека Дункеля.
Они ничего так вполне рабочие, их даже в eCOS применять не стесняются, но уже слабоваты для современного уровня.

Эти оси вообще, для слабоватых процессоров применяют. Если вы и это тоже не заметили.
Если что-то более серьезное, (вплоть до топовых суперкомпьютеров) есть Linux.

Прям обидели фанатов VxWorks-а (космос), QNX-а (атомная энергетика) ... Щас прибегут, затопчут же...
На самом деле есть вполне четкие градации цены-функциональности в осях.
Разбираться просто детально нужно.

Уважаемый, Вы не ошиблись сайтом? баш орг ру немного не тут... Память стоит копейки, а тем более SDRAM, ее стоимость просто тает на глазах, становится просто незначительной. BSP надо не переписывать, а корректировать под свое железо, ибо существуют образцовые платы, например AT91SAM9260-EK или EDB-9302 и т.д., остальные платы - клоны со своими доработками. Настраивается просто и элементарно - потому что все стандартно и привычно, а то, насколько удобно будет работать клиенту - зависит от разработчика. С UNIX железо взлетает просто мгновенно, а то что интегрировано в проц так и подавно, масса устройств работает сразу без танцев с бубном, все USB, все PCI, SD/MMC - запросто, SSH - запросто, то се пятое десятое - элементарно. Без глюков. А если появляются - есть возможность разобраться во всем этом. Вывод: типичный "неосилятор"... =(

Сравнительно простые (с точки зрения оси) задачи.


Это так Канадцам хочется. На самом деле это ось канадских лесопилок. Причем я не знаю как оно сейчас, но уже когда оно называлось "нейтрино", оно было больше вполне нормальным UNIXом. С иксами, GCC итд.


Размазаны они все. Области Linux и QNX во много сильно перекрываются.

LwIP с самого начала поддерживал несколько интерфейсов и имеет зачатки маршрутизации.
Насчет "убийцы" - вопрос спорный - мне кажется что ниши у MQX и перечисленных в топике ОС несколько разные. Упомянутые ОСи - они хороши для "моноконтроллерных" устройств, добавляете внешний чип S(D)RAM - уже "не то" - и ноги "отъедены", и место на плате занято, иногда и микропотребление/спящий режим не обеспечивается.
Посмотрел MQX-овский стек - после обнаружения копирования некоторых отсылаемых пакетов в MAC-драйвере интерес несколько поугас. Так что - мое мнение - MQX всего лишь "один из", а отнюдь не "убийца" . В качестве примера, исходники безусловно полезны.

Вы наверно увидели функцию типа memcpy процедуре ENET_send_MAC
Там написано что это нужно в частности в случае невыровненности данных в буфере.
Почему это может случится?
Тут как раз особенность сложных IP стеков.
В IP стеках для ускорения любят применять зеркальную отсылку пакетов.
Например в пакете Echo при использовании ping-а стек не выделяет новый буфер для ответа,
а просто переставляет адреса ну и там кое-что еще и отсылает обратно.
Все нормально когда маршрут то-же самый.
Но может оказаться такая запись в таблице маршрутизации которая заставит ответу пойти через другой интерфейс,
а этот интерфейс может оказаться PPP или вообще тоннелем c 3-х этажной структурой заголовков.
Тогда отраженный пакет и окажется невыровненным из-за кардинальной смены заголовков.
И тогда его надо перемещать по границе буфера где-то на уровне драйвера.
К тому же данные в связи с особненностью MAC контроллера Freescale могут быть размещены только по границе 4, а лучше 128 (еще быстрее пересылка будет).
При приеме они так выровнены автоматически, а при передаче редко но могут быть исключения.
Ответ пинга через другой интерфейс эт вообщем скорее ошибка роутинга.
Или закольцовывание маршрутов.
Тут нужен уже RIP протокол. И опять же, он есть в открытом MQX!

Вообще не думаю что вы найдете в стеке MQX какие-нить явные ляпы. Такие оси не с потолка стоят по 100 тыс.$ в полном комплекте.
Их используют там где реально надо убить конкурентов скоростью, компактностью, надежностью и ценой конечного изделия.

Я всегда привожу интересный факт, что вот есть роутеры Linksys WRT54G с популярной книжкой как хакать ихний линукс.
Но когда понадобилось сделать еще более дешевые и надежные роутеры с шифрацией WPA/2-PSK linksys выбрал операционку VxWorks!

В той же книжке дается обзор той самой кучи линуксового софта которую можно поставить на WRT54G.
Что мы там видим в первую очередь:
Жесткий список совместимых с софтом моделей. Цифрой меньше или цифрой больше -и можете стреляться, никакой портабельности нет. Софт не полетит и вы ничем ему не поможете.

Из загрузочных каналов только TFTP и HTTP.

Куча каких-то недоделаных пингеров, дамперов, тестеров, килеров, администраторов, WEb апликаций. Куски PPP и PPTP в виде демонов, ясное дело без всякого понятно описанного прикладного API. Тот самый SSH с которым непонятно че делать в интенете.
Как только встречаем какой-то пакет Talisman VPN c IPSec, то оба! он сразу платный, стоп халяве.
И все список кончается. Где тут че-нить для embedded?

Словом кто-бы че не кричал про богатства, универсальность и портабельность линукса в embedded области - это пустой треп.

Та линух вообще полное г-но. Я вашу мысль понял. И как ни нем куча серваков бегает. Ума не приложу. Загадка природы.

Как-то странно получается. Линух, на котором пол инета бегает, с линухом не совместим.

При правильной идеологии интерфейс не должен бы получать для отправки некондиционированные пакеты. В моей реализации стека на такое стоит вообще assert (была серьезная борьба за сквозной zero-copy). В приведенном примере это уже проблема процедуры маршрутизации переложить пакет "правильно" для исходящего интерфейса. Ведь в общем случае интерфейсы могут отличаться не только аттрибутами но и вообще пулами памяти, поэтому, в самом общем случае, при маршрутизации между разнотипными интерфейсами без копирования не обойтись, имхо. И делать это надо "сверху", а не "снизу", на уровне драйвера. Раз драйвер занимается копированием - значит где-то выше уже дали слабину и упростили себе жизнь. Такое допустимо, но восхищения уже не вызывает .


Я даже когда-то купил такой - года 4 назад. Помнится, основной причиной перехода на VxWorks производитель назвал меньшие требования к памяти - стали шустро паять 2МБ SDRAM вместо 8MБ. Я как раз купил версию 2МБ и мне был нужен VPN-клиент. Так вот, в линуксовой версии VPN-клиент был, а вот в VxW - нет , поэтому купленный WRT54G был возвращен в зад.

Впрочем, помнится, речь в топике не про "убийцу" Линукса, а про uCOS/FreeRTOS/ScmRTOS? А эти ОСи - для "монокристалльных" изделий и MQX тут пролезает только "боком" . Сравнили бы уже с eCOS/RTEMS, что ли. VxWorks - тот коммерческий, будет некорректно.

Я бы сказал при правильном компромиссе.
Вероятнее что пакет будет отражен в тот же тип интерфейса. Поэтому весь верхний уровень и не занимается вообще копированием.
Копирование удобнее делать низшему уровню. Ему там виднее как это лучше сделать. Может по DMA иль на ассемблере иль мапировать прямо буферы в дескрипторы MAC контроллера. Собственно отражение только и является источником нежелательных смещений.

Я правда не говорю про MQX. Но они все там примерно одинаково делают. Т.е. пакеты представляют собой цепочки связанных буферов. Каждый из которых идеально выровнен.
Freescale везде использует один и тотже MAC контроллер, поэтому могу точно сказать что дальше буфера мапируются в дескрипторы FEC

А zero-copy далеко не так однозначно дает прирост производительности. Если из Ethernet-а идет запись сразу в файл на блочное устройство типа SD карту то zero-copy может работать гораздо медленее чем в варианте с промежуточным копированием в большой буфер.



Я тож имею линуксовый WRT54G. Так в нем нет SSH.

Поверьте VPN клиент потребляет максимум 100 Кб памяти для кода и еще меньше для данных.
Про MQX яж начал с того что он быстрее и меньше по объему всех заявленных. Так как это "боком"?
Потому что не портирован? Так специалиста это должно радовать, меньше конкурентов будет.

Возможно. У меня сейчас "прицел" на выкидывание сетевых данных на свой контроллер на PCI в MPC83xx, там DMA очень гибкий, вполне можно pbuf-ы сразу заполнять/отдавать. Посмотрим какие будут результаты, но, согласен, такая ситуация далеко не всегда и не везде. А вообще - копирование здорово ПСП жрет, и если его всего 600-800Мбайт/сек (DDR-266), то при паре копирований внутри стека до 100Мбайт/сек по гигабиту подняться будет трудновато.


Там дело не в памяти было, а в том что имелась большая группа энтузиастов, которые написали достаточно много интересного софта для WRT54G, в том числе версию с VPN-клиентом. А вот официалам было недосуг. На сегодня - у меня есть HD-танк, там похожая ситуация - зная Линукс и даже ничего особенно не разрабатывая можно делать много интересных вещей. Появление альтернативных прошивок - вопрос времени (как у Сиабас будет утечка - так вообще сразу ).


Да где ж меньше - сами ж написали, что "несколько килобайт RAM" - это прикол, а предназначено оно для систем 500МГц (и, подразумевается, с кучей памяти). Я бегло просмотрел исходники - мне показалось, что оно почти все базируется на alloc/free, а такой подход явно не для систем, например, с 32К RAM и без MMU. Может я чего недопонимаю?

Правда? Может мне показалось что у Debian Linux список поддерживаемых архитектур [alpha][amd64][arm][armel][hppa][i386][ia64][mips][mipsel][powerpc][sparc] с одинаковым набором из многих тысяч пакетов под каждую архитектуру (каждая из которых включает в себя до нескольких десятков типов систем и все это там работает)? То как Вы обобщаете проблемы, связанные с конкретным семейством роутеров на весь Embedded Linux в целом, очень похоже на желание потрепать нервы людям или просто потроллить. Я все больше в этом убеждаюсь, еще свежи в памяти Ваши перлы на тему ext4

Если у прежде закрытой оси открывают сырцы - это явный признак невозможности менеджмента компании более ее впаривать, т.е. тупо ищутся другие способы - как по мне они уже не помогут.
Насчет Linux - чел просто не в курсе рыночных раскладов - например поставщик двух видов встраиваемых решений - VxWorks и Linux - Wind River в 2008 году отметил внутренний рост заказов именно Linux решений на 48% :

http://www.internetnews.com/dev-news/artic...on+the+Grow.htm

Далее, че-то не видно вообще какого-то преобладания других супер-пупер ОС'ей, кроме Linux, в телефонах, E-Book'ах, рутерах, set-top box'ах и т.д. Ну а про Android/LiMo/MobLin/GENIVI мы пока умолчим, так как через пару лет Linux еще будут ставить и в автомобильные системы.

Ну и где этот убывця ? Где его доля рынка ? Вот когда менеджмент раздуплится, разрабы подсуетятся и супер-пупер ось займет хоть одну десятую процента рынка - тогда и можно будеь о чем-то говорить. А так, согласен - троллинг чистой воды.

P.S. А про TCP/IP у нас "до файрволла не доходит" ...

QEMU умеет. Очень интересный проект, в том числе для кросс-отладки.

Да, QEMU очень хорош, но что если надо отладить не только софт но и железо? Для этого существует GDB - отладка на целевой платформе прямо в "нативном бинарном представлении ARM-ов" прямо с железом, и все это сидя на своем обычном компе Я сказал очевидную вещь для всех, но существуют исключения по всей видимости...