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


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


Только если руки из задницы, и человек никогда 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 яж начал с того что он быстрее и меньше по объему всех заявленных. Так как это "боком"?
Потому что не портирован? Так специалиста это должно радовать, меньше конкурентов будет.