http://www.slac.stanford.edu/econf/C011127/WEBI001.pdf

Выловил в листе RTEMS.

RTEMS = рулеЗЗ?

Ну именно это утверждение можно оставить на совести авторов документа, поскольку варианты возможны, тем более при разной функциональности. Но то, что Linux по жизни никогда рядом с реалтаймом не лежал, и то, что примочки (точнее усечения) при добавлении буковок
RT радикально картину не меняют это так и есть. У меня есть давняя заноза (которая скорее всего не исполнится) - попробовать попилить FreeBSD на этот предмет.

вот тоже интересное сравнение двух RTOS-"монстров" c обреальтаймленным линуксом

выловил в ED2K

Это надо быть монстром - столь кардинально "пилить" большие ОСи...


Вот если бы они RTAI протестировали - было бы еще интереснее.

Вы верно забыли :-), что я пользую не только контроллеры класса ARM7 но и контроллеры класса
Geode :-)
Ну а насчет ядра, его размера, и читабельности исходников Linux c FreeBSD сильно отличаюся не в пользу Linux.

Это -то я помню. Но разве монстровость ОСи зависит от архитектуры проца? Слышал такое от многих. Тогда все-таки не понятно, почему BSD так мало распространена. Хотя NetBSD существует очень давно...

Ну вопервых распространена, но позиционирование ее было совсем не десктопное.
Второе, что она пишется и сопровождается достаточно очерченной группой разработчиков и той Линуксовой вакханалии (с лелеемой иллюзией сопричасности), когда кто угодно пишет что угодно и создает какой угодно дистрибутив просто нет. Соответственно и "распростаненность", как минимум в головах и в интернете поменьше.
Чем, например, определяется распространненность uCOS?. Глядя на первые творения Автора я просто охреневал, но тем не менее Автор решил делать на этом бизнес и сделал. Книжечку выпустил (ничего особенного, так методический материал), но многие учебные заведения взяли ее в качестве оного. Далее посыпались курсовички с привязкой к этой системе. Энтузиасты портов написали (ну очень разного качества) и пошло-поехало..
Заматерела, обезглючила... Весьма распространенная, но совершенно обычная средненькая система.


Она зависит от его мощности, которая у Geode "вполне достаточна" и наличия возможности
старта множества осей на этой платформе. Причем, именно благодаоя платформе, уже на первом этапе без плясок с бубном по урезанию всего и вся и поиску в интернете чьих-то подобных экспериментов (зачастую закончившихся только публикацией bootlog), имеется реально _многократно_
проверенная в работе система.

Нечего валить все в одну кучу - начнем с того, RTEMS это _не_ операционная система в полном смысле этого слова - задачи там линкуются намертво в ядро, и сравнивать ее по функциональности с freebsd/linux'ом это то же самое что сравнивать Palm и Desktop.
Далее - все RT OS'и и надстройки над ними (кроме малоизвестных спецприменения) нервно курят по сравнению с Linux'ом (RTAI/Xenomai), для сомневающихся можно померяться пиписками
А пилить FreeBSD можно до следующего всемирного потопа, если конечно сил и времени немеряно.

С декстопами все более-менее прояснено - XPень + VmWare (или CoLinux) для Linux.Я их (ВУЗы) вполнене понимаю. Так мало литературы по RTOS с привязкой к конкретике, а не сугубо теоретических изысканий - "как на обустроить RTOS на VME плате за 10к$". На таком безрыбии творение Лябросса вполне нормально смотрелось и смотрится.Хм...А что, порты eCos, RTEMS и других популярных осей - они что, не многократно проверенные? Как правило, такие оси управляются ограниченным коллективом, и то, что оседает в основной ветке, вполне качественное. Кроме того, в листах все-таки народ сидит грамотный, и, как правило, быстро и качественно отвечают (например, даже на мои ламерские вопросы).

Полностью согласен! Но для embedded приложений это не важно - там набор задач определен при старте.Где бы почитать про тесты RTAI?

Насчет реального времени все гораздо сложнее. Вопрос не в латентности прерываний, а в том, насколько сервисы оси RT. Т.е. в чтобы в критических местах я смог нормально использовать семафоры, mail box и пр., а не просто получить управление и писать "ОСь внутри ОСи". Вот как раз по этому параметру RTEMS, похоже, вне конекренции из GPL осей.

Хорошо бы также eCos померить....

Вы это как-то с цитированием или с пониманием написанного поаккуратнее,
поскольку именно я и не валю все в одну кучу и УЖЕ писал о разной функциональности сравниваемого.


Ну это Вы "по привычке" сказали. На самом деле в системе отличающейся от законченной черной коробочки иметь отдельные подгружаемые приложения во многих случаях весьма пользительно.
Я так даже на Am186CC делал - затраты на организацию минимальны, зато получаем МАКСИМАЛЬНО независимую работу разных разработчиков (ядро системы, непосредственная работа с железом, основные алгоритмы,диагностика) и возможность объектового upgrade/переконфигурации нужного компонента без поиска всей компании и вспоминания чего на конкретном объекте конкретно
находится.
Ибо специфика продукта в том, что двух одинаковых по софту продуктов нет, да и по составу периферии варианты десятками идут.
В использование разными разработчиками разных привычных им инструментов тоже хорошо ложится на все это.
Еще одна причина - экономия памяти. Очень удобно отдельные задачи (диагностика оператором, например) загружать по необходимости, при этом будут выгружены некоторвые несущественные
приложения (например, ежечасная калибровочная процедура).

Ну так и сравнивать нужно в классах этих двух систем, т.е. ecos/rtems/nucleus/freertos/tornado/etc. и qnx/winz/linux/etc. Толку от сравнения крокодилов со свиньями я не вижу ни какого.



Про тесты можно почитать в евойной рассылке, есть также livecd с набором тестов. Результат как показывает практика сильно зависит от "правильности" чипсета на котором собрана мамка - дешевые чипсеты с полностью интегрированной периферией показывают худшие результаты, чем надежные решения от промпроизводителей.



В RT оси нет не-RT сервисов, иначе не RT-ось, другое дело как эта ось построена и как irq storm и сложный набор задач с разными приоритетами будет ею обрабатываться, так же в случае RTAI/Xenomai - как низкоприоритетная задача aka Linux будет влиять на устойчивость параметров RT оси.



Опять 25 - а чего BIOS тогда не померять - тоже вроде как embedded ось

Пожалуй, соглашуь с Вашими аргументами.


Странно, я думал с точки зрения RTOS (без графики) все чипсеты одинаковы (с точностью до трудноизмеряемых параметров)....

Тогда, я пожалуй и читать не буду, поскольку объективность таких "результатов" еще ниже
принятой среди куликов хвалящих свое болото :-(

Это сущие пустяки, когда всерьез начнете "пилить" FreeBSD, времени "на посмотреть на другие результаты" уже просто не будет. Смелее, нам тоже всем интересно - чем так сказать закончиться, если оно конечно когда нибудь начнется

Тогда не стоило об этом распространяться.

Вот и я об этом, прежде чем говорить о переделке полноценной ОС в RT вариант, нужно или иметь на руках preliminary патчи для нее, что бы можно было сравнить реализации с уже так сказать существующими критикуемыми вариантами, прикинуть возможный набор сервисов и т.д. О том чтобы иметь трезвую оценку по трудозатратам и хотя бы приблизительно представлять _как_ (разумеется в контексте современной конкурентно-способной реализации оного RT варианта) это сделать я уже даже и не говорю.
Наблюдается тенденция критики того с чем не хватило сил грамотно разобраться - вот отсюда и вытекает большинство поделок на коленках, которые применить больше чем к одной задаче и одним программистом ну никак не выходит. Sorry, это не мой путь точно - как говорится в одном известном мультике - "лучше день потерять - потом за 5 минут долететь".

Это Вы все сами додумали, хотя и не без оснований, поскольку действительно в топике поминается RTOS. А был (перечитал реплику и понял) слишком лаконичен :-(
О "полноценной" RTOS из FreeBSD речь не идет абсолютно, по той-же причине по которой я скептически отозвался о RTLinux. Мое поминание FreeBSD относилось к правкам, ну давайте назовем их "косметическими", которые приблизят ее "реалтаймовости" RTLinux. Причем у меня существует некоторая внутренняя уверенность, что до достижения результатов RTLinux правки
потребуются "косметическо"/хирургические ("пилить"). Ну вот теперь вроде ясно изъяснился.


Это в мой адрес? Тогда конкретизируйте.

Во-во, лапидарнее надо быть и тщательнее



Никак не приблизят. Если Вы против - просим лапидарные патчи в студию.

Ваши слова - против моих слов. Только я к и к Linux и к RTLinux, и особенно FreeBSD присматривался, а Вы похоже "за проcто так" поговорить решили :-(.
Если прогнозируемый проект к весне поднимится, то патчей в открытой раздаче не будет, это без вариантов. Так-что можете продолжать совершенно безопасно стебаться дальше.

Мимо, лапидарный Вы наш - у меня два конкретных проекта пашуть - один под rtai-hal (этот вариант считается уже официально устаревшим), второй под rtai-over-adeos. Следующий проект будет делаться на xenomai, т.е. вообще без rtai.



Это мне напоминает песню манго-манго "у нас есть такИе приборы ! но мы вам о них не расскажем".

P.S. Что-то не наблюдается конструктива в сиих обсуждениях ;(

Ни где, ни слова ни пол слова не было упомянуто слово "есть". С самого начала были декларированы
исключительно намерения.


Я гдето упрекнул Вас в незнании rtai-hal? Или у Вас еще чего много, включая первопричину раздора - FreeBSD пашет? Причем при свой выбор Вы можете как-то обосновать? Или его включили и оно "заработало"? Так вот вариант с Linux, который "заработало" уже с 90x годов имеется и имеется осознание того, куда двигаться в случае необходимости.


Наредкость :-(.

Любители и ! любители лапидарности

Вынужден обратить ваше внимание на то, что вы подошли к опасной черте взаимных оскорблений.

Парни, вы чего?

По существу - а по чему бы не рассмотреть RTEMS? Он в большей степени Unix, чем eCos. По файлам и Pthreads точно. Ну и с RT там все очень даже ничего.

Понятно, там нет динамической загрузки процессов - но есть много чего другого интересного.

Лицензия правильная - можно линковать со своей нетленкой без раскрытия исходников оной.

Нет смысла рассматривать RTEMS и им подобные "конгломераты". В настоящее время когда космические корабли бороздят, брр... когда армы стоят меньше $1, sdram'ой на плате никого не удивишь и на nios2/microblase в fpga можно поднять linux - я не вижу в RTEMS-подобных системах смысла - слишком много накладных расходов на обеспечение стандартной функциональности OS (сеть/графика/ipc/диски/fs и т.д.). Более того - много кода который уже годами катит на юниксах для rtems систем придется переделывать, так как отсутствуют многие standart de-facto системные вызовы (mmap например). А другую часть кода придется создавать по новой - дравер pci шины или устройства на ней. И последний немаловажный аргумент - rtems-подобные оси имеют намного меньшую аудиторию юзеров - соответственно больше ошибок, меньшую скорость разработки/обновления и большую стоимость поддержки.
Хотя есть класс задач, в который они возможно и вписываются - вот например мне интересно сделать SIP телефон на sam7x/sam7se - linux туды не влезет, а с другой стороны и rtems/ecos там тоже слишком громоздко выглядят, все можно сделать компактнее и проще.

P.S. Насчет перепалки - товарищ просто "не в теме", видать программер которому уже далеко за 40, написавший за свою жизнь на x86 асме пару досовских приблуд, которые идут на одном и том же железе. Если честно мне уже самому надоело {пи-пи-пи-пи}
===
Сообщение отредактировано модератором.

Harbour - я не понимаю, зачем пересекать ту самую черту, о которой я писал выше?

Получаете устное предупреждение.

Это типа Ваш "последний" аргумент? Не прояснил совершенно ничего :-(, хотя я теперь знаю, как к
вАМ следует относиться.