Представлен (http://linuxdevices.com/news/NS8393438079.html) проект Xenomai/SOLO (http://www.denx.de/cgi-bin/gitweb.cgi?p=xenomai-solo.git;a=b...), являющийся реализацией режима эмуляции RTOS систем, при использовании стандартного Linux ядра. В отличие от других проектов, таких как Xenomai (http://www.xenomai.org/index.php/Main_Page), нет необходимости в наложении патчей или в установке дополнительных модулей ядра, - все реализовано на пользовательском уровне.
Для работы Xenomai/SOLO требуется свежая версия библиотеки glibc с поддержкой NPTL нитей и режима PTHREAD_PRIO_INHERIT. Желательна, но не обязательно, установка Linux ядра с включенными real-time расширениями PREEMPT_RT (http://rt.wiki.kernel.org).
Проект позволит значительно упростить процесс портирования RTOS приложений, например, первым достижением Xenomai/SOLO стала возможность пересборки с новым фреймворком эмулятора VxWorks.URL: http://linuxdevices.com/news/NS8393438079.html
Новость: http://www.opennet.me/opennews/art.shtml?num=14900
не совсем понятно, зачем это надо?
Linux уже научился показывать лучшее реальное время нежели традиционные продукты этого сегмента?
или это надо исключительно для разработки ?
Совсем не понятно что такое "лучшее реальное время" - гимп рисует лучший красный цвет чем фотожоп?
Лучшее - это когда ГИМП всегда будет зарисовывать, скажем квадрат 500х500 pix,
на CPU в 2GHz за 0.0012153 сек. и затратив на это 2.4306*10^6 тактов.ЗАМЕЧУ - ВСЕГДА за 0.0012153 сек, а не как Фотошоп - по настроению Windows.
Для того, чтоб прочувствовали - скажите 100 раз - "ОПЕРАЦИОННАЯ СИСТЕМА РЕАЛЬНОГО ВРЕМЕНИ",
за столько же времени, за сколько сказали в первый раз.
Что!?! В мозгах кэшируется, а язык-то заплетается?! :)
Пример не тот, у RTOS немного другие задачи :) Как пример, это когда на производстве одновременно приходит 100 сигналов от датчиков и все они должны быть обработаны в строго ограниченные временные рамки (рамики все таки есть), но не более порогового значения.
>Пример не тот, у RTOS немного другие задачи :) Как пример, это
>когда на производстве одновременно приходит 100 сигналов от датчиков и все
>они должны быть обработаны в строго ограниченные временные рамки (рамики все
>таки есть), но не более порогового значения.Но все создатели RTOS только об этом и мечтают...
Немного не так.
В ОС реального времени каждая обработка должна выполняться в строго заданое время. В Linux хоть и меньше латентность, но нет никакой гарантии, что требуемая операция будет выполнена в строго заданое время. В реальных задачах в системах не реального времени (Linux и т.д.), приходится расчитывать так опрос, например датчика, чтобы он начинался гарантировано раньше поступления с него данных, при этом процесс ожидает прихода данных. После получения данных идет уже обработка. Вот и получается, что более короткую латентность и процессорное время тратят на ожидание и переключение между процесами. В РТОС все заранее просчитывается и для получения адекватного результата нужно меньшую частоту процессора и все вытекающие из этого последствия.
Офисные приложения, фотошопы и т.п. не требуют реально времени выполнения, это не те цели.
лучшее в данном контексте - меньшее.
то есть при прочих равных Linux должен показывать большую скорость реакции и меньшую латентность по сравнению с VxWorks или QNX
а сравнивать RT с цветом по-моему не вполне профессионально, или это у вас стеб такой?
До QNX ему как пешком до африки... Я думаю это всё всё-таки для разработки делается.
+1
> ... или это у вас стеб такой?Дошло?! А то я уж боялся что у тебя как у павлина чувство юмора в нокауте...
"Реальное время" оно либо есть (будь то жёсткое или мягкое), либо нет. И со "скоростью реакции", "латентностью" и прочим оно соотноситься как с цветом - это перпендикулярные понятия. Так же как и красный цвет в графическом редакторе - нельзя нарисовать "лучший" просто потому, что его либо можно нарисовать, либо нет: оно не бывает лучше\хуже.
>"Реальное время" оно либо есть (будь то жёсткое или мягкое), либо нет.Не вполне согласен - "мягкое" РВ - это фактически отсутсвие РВ.
РВ вполне измеряемо, и если гарантированное время реакции в VxWorks допустим 10 мс, а в Linux 30, то очевидно, что VxWorks по этому параметру лучше.
Собственно именно это я и имел ввиду, когда говорил о лучшем РВ.
Зато быдло-менеджеры из Novell уже дистр продают, SLES RT, хотя там лишь жалкий soft real time, но зато, как звучит, Real Time Linux, ура мелкомяхким половым связям, они зделали своё дело с Novell!!!*MRAK*
>Зато быдло-менеджеры из Novell уже дистр продают, SLES RT, хотя там лишь
>жалкий soft real time, но зато, как звучит, Real Time Linux,
>ура мелкомяхким половым связям, они зделали своё дело с Novell!!!*MRAK*А что вас так злит? Люди зарабатывают деньги, видимо кого-то это решение устраивает по своим возможностям.
> А что вас так злит? Люди зарабатывают деньги, видимо кого-то это решение устраивает по своим возможностям.Меня это не злит вовсе, мне то что от этого, пусть зарабатывают, естественно это кого-то устраивает, лижбы это в целом GNU движению не мешало, я имею ввиду их половые связи с мелкомяхкими...:)
А что, были замечены негативные последствия этих связей? Все только на пользу.
Вряд ли тот кто десятилетиями разрабатывал систему под VxWorks реально захочет все переписывать с нуля телько для того, чтобы перенести свой продукт на Linux. Для масштабных проектов всегда требуется время. Одним из примеров является Nortel - большинство их PABX (включая IP тел. станции) работаеют по VxWorks.
А смысл то в чем переносить? Это нужно, как среда разработки для новых проектов, хотя сомнительно, что удастся создать полную эмуляцию (личное мнение).
Ну мож хоть видео можно будет 99.9% заставить без рывков и артефактов всяких показывать. А то софтверные проигрыватели сливают в этом плане всяким dvd пепельницам
>Ну мож хоть видео можно будет 99.9% заставить без рывков и артефактов
>всяких показывать. А то софтверные проигрыватели сливают в этом плане всяким
>dvd пепельницамСофт против аппаратно реализованного кодека всё равно не канает.... Купите видюху поприличнее - не будет ничего логать - у меня в VLC на х800 HDTV почти не лагает.
А вот как раз и интересует полный реал тайм, когда ЦПУ только и занят потоком видео. В общем то грамотно написанный и использующий SSE3 алгоритм может с точностью до герца расчитать требуемую частоту процессара, учитывая конечно же и архитектуру системы в целом...
Другое дело, что HDTV проприетарщина :(