[d-kernel] Alt_linux_RTOS или Alt_RTLinux_free- насколько это возможно?

[d-kernel] Alt_linux_RTOS или Alt_RTLinux_free- насколько это возможно?

[gosha]

                                                      Добрый день.

     Такая проблема: заказчик требует установки Unix RTOS на блок.

     По приведенным ссылкам утверждается, что если у Linux kernel полностью 
отключить swap-file (что делает время реакции системы недетерминированным, 
понятие RTOS и файл подкачки несовместимы) и приложить данные patch - ядро 
Linux превращается в hard realtime.

http://ru.wikipedia.org/wiki/RTLinux
http://www.rtlinuxfree.com/
http://www.windriver.com/announces/rtlinux/

    Компания Wind River - довольно авторитетная компания, разработчик ОС, 
высоконадежной и дорогой RTOS VxWorx (на осн которой летали ситемы упр 
марсоходов) (более дорогой и надежной, чем QNX):
http://www.computerra.ru/pda/index.php?action=article&section_id=26058&id=31622




    Вопрос: насколько ,по Вашему мнению, данные patch смогут "легко 
превратить" Alt_Linux в RTOS?

     Насколько возможно приложение данных patch к ядру Alt_Linux  (включая x86 
архитектуру)?

    Насколько, по Вашему мнению, это лицензионно возможно?

    Насколько возможна постройка установочного DVD/CD (включая x86 
архитектуру), где устанавливается  пропатченое ядро, не затрагивая прочих 
пакетов?

    Насколько рельно, что в розничной продаже параллельно с Alt_LInux сервер и 
Alt_Linux desktop появится Alt_Linux_RTOS ? С этикеткой RTOS, которую можно 
предоставить заказчику?


Спасибо.
-- 
С Уваженим,
       gosha.

Re: [d-kernel] [devel-ports] Alt_linux_RTOS или Alt_RTLinux_free- насколько это возможно?

[Wartan Hachaturow]

2008/3/7 gosha <gosha@elins.ru>:

>      Такая проблема: заказчик требует установки Unix RTOS на блок.

Что конкретно имеется в виду под "RTOS"? Soft RT, Hard RT?

>      По приведенным ссылкам утверждается, что если у Linux kernel полностью
>  отключить swap-file (что делает время реакции системы недетерминированным,
>  понятие RTOS и файл подкачки несовместимы) и приложить данные patch - ядро
>  Linux превращается в hard realtime.

Нет, не превращается. Бесплатных завтраков не бывает :)
Чтобы оно стало настоящим RT, все используемые в проекте драйвера
нужно переписать, чтобы они работали в RT-контексте. Ну и, разумеется,
нужно соответствующим образом писать приложения.
Существующий код от приложения патча RT не станет.

>  http://ru.wikipedia.org/wiki/RTLinux
>  http://www.rtlinuxfree.com/
>  http://www.windriver.com/announces/rtlinux/

Их много. RTAI, Xeonmai.

>     Компания Wind River - довольно авторитетная компания, разработчик ОС,
>  высоконадежной и дорогой RTOS VxWorx (на осн которой летали ситемы упр
>  марсоходов) (более дорогой и надежной, чем QNX):

VxWorks. Утверждение про надёжность спорно :)

>     Вопрос: насколько ,по Вашему мнению, данные patch смогут "легко
>  превратить" Alt_Linux в RTOS?

Лично я не вижу никакого смысла. Если нужно разрабатывать generic
embedded решение на Linux с RT-возможностями, то это отдельная задача,
и от собственно ALT Linux там не будет почти ничего. И как я уже
сказал, патчи не превращают существующий код в RT.

>      Насколько возможно приложение данных patch к ядру Alt_Linux  (включая x86
>  архитектуру)?

Приложить можно, отчего не приложить :) Опять же -- зачем? KDE от
этого не будет работать быстрей :))

>     Насколько, по Вашему мнению, это лицензионно возможно?

У RTLinux есть какие-то патентные проблемы, но они раздают свои патчи
под GPL. RTAI с самого начала свободный.

>     Насколько рельно, что в розничной продаже параллельно с Alt_LInux сервер и
>  Alt_Linux desktop появится Alt_Linux_RTOS ? С этикеткой RTOS, которую можно
>  предоставить заказчику?

Нереально. Это разные миры и разные задачи. Во всяком случае, я этого
делать не буду. Если возникнет необходимость подобного проекта, а
также соответствующее финансирование, я сделаю, но это будет иметь
очень и очень опосредованное отношение к дистрибутиву ALTLinux  в его
нынешнем виде.

-- 
Regards, Wartan.

Re: [d-kernel] [devel-ports] Alt_linux_RTOS или Alt_RTLinux_free- насколько это возможно?

[Wartan Hachaturow]

2008/3/7 gosha <gosha@elins.ru>:

>      Но, если взять задачи управления, напр технологическим оборудованием
>  (ЧПУ) и пр.. Критичная ко времени часть помещается в RTOS модуль (анализ
>  сигналов с датчиков, расчеты и выдачу управляющего воздействия) (как это
>  рекомендуется в RTLinux-howto
>  http://www.faqs.org/docs/Linux-HOWTO/RTLinux-HOWTO.html).

Да, всё так.

>
>     Тогда требуемое управляющее воздействие на объект управления будет выдано
>  за количество милисекунд, оговоренное в техническом задании на систему
>  управления (САУ).

Теоретически -- да.
Есть ещё одна тонкость. В принципе говоря, в серьёзных приложениях
RT-шность требуется доказывать. Например, формальной верификацией. Для
кода RTLinux/RTAI это задача неподъёмная. Если достаточно, например,
результатов тестирования, то это вполне можно сделать.

>     Таким образом, выполнив рекомендации RTLinux_free по написанию RTOS части
>  прикладной задчи, мы получим требуемую САУ, И Alt_Linux может использоваться
>  как ОС для построения САУ. Причем RTOS не будет стоить баснословных средств,
>  которые явно не устроят заказчика. И будет Open Source (что устраивает ФСБ).

Что есть ALTLinux? ALTLInux есть ядро плюс userland.
Что именно из имеющегося в альте userland'а понадобится?
Я так понимаю, что почти ничего. Во всяком случае, на самой железке.
На рабочем месте разработчика -- может быть, да.
Ядро для подобной задачи придётся сильно переделать (поотрывать
ненужное, скорее всего, сдаунгрейдить).
Зачем тогда нужная львиная доля того, что есть в альте?
Получающееся решение будет сильно специфичным для задачи и не будет
дистрибутивом. Я ровно об этом говорю. Можно сделать на базе Альта
конструктор такого типа решений, но я примерно представляю себе объём
работ, и он очень серьёзный.

>     Но для этого необходимо, чтобы один из дистрибутивов Alt_Linux
>  позиционировался как RTOS с соотв этикеткой, которую можно предоставить
>  заказчику.

*Дистрибутив* не будет RTOS.

>     Если стоит задача пересборки kernel, то я могу (безвоздмезно) попробовать
>  наложить данные patch и написать простенькую САУ (напр для сигналов с
>  параллельного порта) (для x86 и MIPS).

Попробуйте, конечно. Будет интересно почитать.

>     Но интересовало бы стороннее мнение, насколько это действительно будет
>  востребовано кроме как в нашей задаче.

Теоретически перспектива создать такое отечественное решение
(конструктор) выглядит приятной. И то, что можно сделать, будет
значительно лучше МСВС. Однако на это нужны серьёзные ресурсы. Как
человеческие, так и капитальные.

>     Напр, как утверждают, выбор процессоров AMD по сравнению с Intel
>  пользователями чаще всего происходит за счет того, что система построенная на
>  базе процессоров AMD дешевле, при аналогичных характеристиках с Intel.

Дело не в дешевизне. WindRiver и QSSL (теперь Harmann) -- компании с
солидным опытом работы на этом рынке, со всевозможными сертификациями
своих решений и очень большим количеством внедрений. Им просто
доверяют, и готовы за это платить. Если вы делаете mission-critical
железку, то цена вас хоть и интересует, но не в первую очередь.

-- 
Regards, Wartan.

Re: [d-kernel] [devel-kernel] Alt_linux_RTOS или Alt_RTLinux_free- насколько это возможно?

[gosha]

                                                Добрый день.

WAX> Нет, не превращается. Бесплатных завтраков не бывает :)
WAX> Чтобы оно стало настоящим RT, все используемые в проекте драйвера
WAX> нужно переписать, чтобы они работали в RT-контексте. Ну и, разумеется,
WAX> нужно соответствующим образом писать приложения.
WAX> Существующий код от приложения патча RT не станет.

     
     Вопрос обсуждения RTOS далеко не праздный, т.к. необходимо за 1 год 
сделать САУ на RTOS с открытыми исходниками для блоков с процессорами MIPS, 
которая в последствии будет рекомендована к применению.
 
     На применение отечественных ОС заказчик смотрит более доверчиво, хотя 
качество отечественных ОС по прежнему остается не очень высоким.



     KDE и отрисовка, действ, не будут работать быстрее. 

     Но, если взять задачи управления, напр технологическим оборудованием 
(ЧПУ) и пр.. Критичная ко времени часть помещается в RTOS модуль (анализ 
сигналов с датчиков, расчеты и выдачу управляющего воздействия) (как это 
рекомендуется в RTLinux-howto 
http://www.faqs.org/docs/Linux-HOWTO/RTLinux-HOWTO.html). 

    Тогда требуемое управляющее воздействие на объект управления будет выдано 
за количество милисекунд, оговоренное в техническом задании на систему 
управления (САУ).

     Как я понимаю, переписывается (или патчится) только штатный обработчик 
прерывания Linux Kernel, который определяет прерывание как RTOS/не_RTOS. И 
определяет, есть ли RTOS работа (напр выдача управления на объект управления 
с фиксированным шагом по времени).

    Таким образом, выполнив рекомендации RTLinux_free по написанию RTOS части 
прикладной задчи, мы получим требуемую САУ, И Alt_Linux может использоваться 
как ОС для построения САУ. Причем RTOS не будет стоить баснословных средств, 
которые явно не устроят заказчика. И будет Open Source (что устраивает ФСБ).

    Дешевизна Alt_Linux по сравнению с QNX (18 килобаксов), возможно, может 
оказаться решающим критерием для выбора ОС при разработке САУ прочими 
разработчиками, Даже если с написание прикладной задачи придется немного 
помучаться.

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

    Если стоит задача пересборки kernel, то я могу (безвоздмезно) попробовать 
наложить данные patch и написать простенькую САУ (напр для сигналов с 
параллельного порта) (для x86 и MIPS).

    Но интересовало бы стороннее мнение, насколько это действительно будет 
востребовано кроме как в нашей задаче.

    Напр, как утверждают, выбор процессоров AMD по сравнению с Intel 
пользователями чаще всего происходит за счет того, что система построенная на 
базе процессоров AMD дешевле, при аналогичных характеристиках с Intel.

    
   Спасибо.
-- 
С Уваженим,
       gosha.



> >      Такая проблема: заказчик требует установки Unix RTOS на блок.
>
> Что конкретно имеется в виду под "RTOS"? Soft RT, Hard RT?
>
> >      По приведенным ссылкам утверждается, что если у Linux kernel
> > полностью отключить swap-file (что делает время реакции системы
> > недетерминированным, понятие RTOS и файл подкачки несовместимы) и
> > приложить данные patch - ядро Linux превращается в hard realtime.
>

>
> >  http://ru.wikipedia.org/wiki/RTLinux
> >  http://www.rtlinuxfree.com/
> >  http://www.windriver.com/announces/rtlinux/
>
> Их много. RTAI, Xeonmai.
>
> >     Компания Wind River - довольно авторитетная компания, разработчик ОС,
> >  высоконадежной и дорогой RTOS VxWorx (на осн которой летали ситемы упр
> >  марсоходов) (более дорогой и надежной, чем QNX):
>
> VxWorks. Утверждение про надёжность спорно :)
>
> >     Вопрос: насколько ,по Вашему мнению, данные patch смогут "легко
> >  превратить" Alt_Linux в RTOS?
>
> Лично я не вижу никакого смысла. Если нужно разрабатывать generic
> embedded решение на Linux с RT-возможностями, то это отдельная задача,
> и от собственно ALT Linux там не будет почти ничего. И как я уже
> сказал, патчи не превращают существующий код в RT.
>
> >      Насколько возможно приложение данных patch к ядру Alt_Linux 
> > (включая x86 архитектуру)?
>
> Приложить можно, отчего не приложить :) Опять же -- зачем? KDE от
> этого не будет работать быстрей :))
>
> >     Насколько, по Вашему мнению, это лицензионно возможно?
>
> У RTLinux есть какие-то патентные проблемы, но они раздают свои патчи
> под GPL. RTAI с самого начала свободный.
>
> >     Насколько рельно, что в розничной продаже параллельно с Alt_LInux
> > сервер и Alt_Linux desktop появится Alt_Linux_RTOS ? С этикеткой RTOS,
> > которую можно предоставить заказчику?
>
> Нереально. Это разные миры и разные задачи. Во всяком случае, я этого
> делать не буду. Если возникнет необходимость подобного проекта, а
> также соответствующее финансирование, я сделаю, но это будет иметь
> очень и очень опосредованное отношение к дистрибутиву ALTLinux  в его
> нынешнем виде.

Re: [d-kernel] [devel-kernel] Alt_linux_RTOS или Alt_RTLinux_free- насколько это возможно?

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 182 bytes --]

Twas brillig at 12:30:11 07.03.2008 UTC+00 when gosha did gyre and gimble:

 g> Alt_Linux

Прошу употреблять термин правильно - ALT Linux.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [d-kernel] ALT Linux RTOS или ALT RTLinux free -- насколько это возможно?

[Michael Shigorin]

On Fri, Mar 07, 2008 at 12:30:11PM +0000, gosha wrote:
> Дешевизна Alt_Linux по сравнению с QNX (18 килобаксов),
> возможно, может оказаться решающим критерием для выбора ОС при
> разработке САУ прочими разработчиками, Даже если с написание
> прикладной задачи придется немного помучаться.
> Но для этого необходимо, чтобы один из дистрибутивов Alt_Linux
> позиционировался как RTOS с соотв этикеткой, которую можно
> предоставить заказчику.

Для этого требуется выполнить соответствующий проект, что требует
вложения либо времени, либо денег.  Первый раз может получиться 
и подороже QNX (я не в курсе, сколько бы те же мы взяли за такие
работы), но результат может получиться более дешёвым в
копировании и повторном применении.

Сравнивать "дешевизну" ALT Linux, не являющегося RT вообще,
и QNX, являющегося RT by design, смысла не вижу.

> Если стоит задача пересборки kernel, то я могу (безвоздмезно)
> попробовать наложить данные patch и написать простенькую САУ
> (напр для сигналов с параллельного порта) (для x86 и MIPS).

Ну попробуйте -- может, заказчику этого и достаточно...

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [d-kernel] [devel-kernel] Alt_linux_RTOS или Alt_RTLinux_free- насколько это возможно?

[gosha]

                                                Добрый день.

WAX> Их много. RTAI, Xeonmai.

           Спасибо за ссылки.

           Огласите весь список, пожалуйста.

-- 
С Уваженим,
       gosha.     

Re: [d-kernel] [devel-kernel] Alt_linux_RTOS или Alt_RTLinux_free- насколько это возможно?

[Wartan Hachaturow]

2008/3/7 gosha <gosha@elins.ru>:
>                                                 Добрый день.
>
>  WAX> Их много. RTAI, Xeonmai.
>
>            Спасибо за ссылки.
>
>            Огласите весь список, пожалуйста.

Ну, помимо уже упомянутых RTLinux, RTAI и Xenomai ещё есть Инговская
-rt ветка, но там hard rt никто не обещает, там просто обещают быструю
реакцию (soft rt :). Есть ещё пачка решений, где Linux пускают
процессом поверх RT-ядра. Они есть проприетарные (вагон, по именам
даже не знаю), есть открытые, вроде Linux поверх L4.
Собственно, off the top of my head вроде всё.
В сети есть пачка обзоров на тему real time linux solutions, можно погуглить.

-- 
Regards, Wartan.

Re: [d-kernel] ALT Linux RTOS или ALT RTLinux free -- насколько это возможно?

[Michael Shigorin]

On Fri, Mar 07, 2008 at 12:53:26PM +0300, Wartan Hachaturow wrote:
> В сети есть пачка обзоров на тему real time linux solutions,
> можно погуглить.

На http://lwn.net неплохие (на мой дилетантский вкус) бывали.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[d-kernel] Как правильно пересобирать .rpm ядра 2.6.18 std для х86?

[gosha]

                                                Добрый день.

Используется Alt Linux 4 desktop.

Используется машина x86.

Никакой кросс-сборки.

при выполнении rpmbuild -bb  kernel-source.spec

устойчиво собирается только src.rpm

Что необходимо сделать, чтобы собрался binary i586.rpm ?

Спасибо.

-- 
С Уваженим,
       gosha.     

Re: [d-kernel] Как правильно пересобирать .rpm ядра 2.6.18 std для х86?

[Alexey Shabalin]

13.03.08, gosha написал(а):
>                                                 Добрый день.
>
>  Используется Alt Linux 4 desktop.
>  Используется машина x86.
>  Никакой кросс-сборки.
>  при выполнении rpmbuild -bb  kernel-source.spec
>  устойчиво собирается только src.rpm
в имени спека source Вам ни о чём не говорит? :)
>  Что необходимо сделать, чтобы собрался binary i586.rpm ?
логично, что-то типа rpm -bb kernel-image.spec



-- 
Alexey Shabalin

[d-kernel] Как правильно пересобирать .rpm ядра 2.6.18 std для х86?

[gosha]

                                                Добрый день.

A_Sh> логично, что-то типа rpm -bb kernel-image.spec

Спасибо. Все собралось.

   #rpm -target=i586 -bb kernel-image.spec<cr>

-- 
С Уваженим,
       gosha.     

[d-kernel] q: 2.6.24.3

[gosha]

                                                Добрый день.

>> Никто не в курсе, что по части безопасности правили в 2.6.24.3?

Это про http://www.unix.org.ua/news/view.php?id=2062 ?

-- 
С Уваженим,
       gosha.