Исследовательский центр Digital Human Research Center при Токийском Национальном Политехническом Институте (AIST), анонсировал (http://sourceforge.net/mailarchive/forum.php?thread_name=4C8...) в почтовой рассылке, о выпуске новой версии проекта ART Linux (http://art-linux.sourceforge.net/) (Advanced Real-Time Linux), базирующейся на Linux-ядре 2.6.32. Для загрузки доступны (http://www.dh.aist.go.jp/en/research/humanoid/ART-Linux/) как готовый пакет для Ubuntu Linux 10.04, так и исходные тексты.По мнению разработчиков, закрытые RTOS страдают недостатком поддерживаемого, как программного, так и аппаратного обеспечения.
Так же, проблемы в открытых проектах, - для RTLinux и Linux/RT требуются специальные драйверы для совместимости с требованиями реального времени. В ответ на это, ART Linux имеет:
- Планировщик Жесткого Реального Времени;
- Защиту памяти для задач Реального Времени;
- Задачи Реального Времени могу сосущ...URL: http://sourceforge.net/projects/art-linux/
Новость: http://www.opennet.me/opennews/art.shtml?num=27907
Милые ребята# make
...
...
In file included from include/linux/sched.h:95:0,
from arch/x86/kernel/asm-offsets_64.c:9,
from arch/x86/kernel/asm-offsets.c:4:
include/linux/art_task.h: In function 'art_inherit':
include/linux/art_task.h:78:9: error: 'struct thread_info' has no member named 'art_task'
include/linux/art_task.h: In function 'art_dispatch':
include/linux/art_task.h:89:41: error: 'struct thread_info' has no member named 'art_task'
In file included from arch/x86/kernel/asm-offsets.c:4:0:
arch/x86/kernel/asm-offsets_64.c: In function 'main':
arch/x86/kernel/asm-offsets_64.c:51:2: error: 'struct thread_info' has no member named 'art_task'
make[1]: *** [arch/x86/kernel/asm-offsets.s] Error 1
make: *** [prepare0] Error 2
Ну ты ж новость запостил, это мы к тебе должны претензии высказывать )))
похоже, их реальное время слегка мягкое и попахивает.ЗЫ бывает нежесткое реальное время? ;)
Ну как бы да. Кошерность его с академической (да и технологической) точки зрения, конечно, под вопросом. Но термин такой есть. Пруфлинк: http://en.wikipedia.org/wiki/Real-time_computing#Hard_and_so...
>Ну как бы да. Кошерность его с академической (да и технологической) точки
>зрения, конечно, под вопросом. Но термин такой есть. Пруфлинк: http://en.wikipedia.org/wiki/Real-time_computing#Hard_and_so...термин-то можно придумать для чего угодно. но, имхо, от таких наполовину беременных маркетингом попахивает.
"Операционная система реального времени - операционная система с *гарантированным* временем реакции на событие."
>термин-то можно придумать для чего угодно. но, имхо, от таких наполовину беременных
>маркетингом попахивает.Совершенно верно. Поэтому я и написал "как бы". Хотя, для некоторых задачь это действительно может (я не очень-то специаллист тут, банальная эрудиция) иметь смысл и быть рациональным вариантом. Например студийные задачи, в противовес высокоответственным и промышленным задачам, где требуется настоящий гарантированный рилтайм
ММммм.... Не совсем так. Тогда скажите что время реакции системы не превышает 1 год и... Любая ОС становится ОС реального времени.На самом деле, все чутка по другому. Важно не столько время реакции (лишь бы оно не превышало некую, достаточно небольшую величину, зависящую от области применения - от десятков наносекунд до секунд). Тут важнее другое - при любой интенсивности входящих событий ОС РВ должна их ВСЕХ обработать за оговоренную дельту. В реальной жизни такого не может быть, потому как в любом случае повышая интенсивность возникновения событий мы любую систему ставим раком - она либо растит очередь и теряет гарантированную дельту, либо начинает пропускать события, что тоже недопустимо.
Таким образм все разговоры о "реальном времени", а особенно "жестком реальном времени" в действительности обычный маркетинг. Реальное отличие таких ОС от остальных - сильно сокращенное время реакции на события (читай быстрое переключение контекстов), что позволяет в пиках загрузки успевать отработать большее их количество.
В общем и целом - можно создать условия, при которых и ванильное ядро можно будет считать яром жесткого реального времени, а можно создать и такие, что и эти патчи нагрузку не потянут.
> Любая ОС становится ОС реального времени.только денег на ней на этом рынке можно заработать не более нуля.
> при любой интенсивности входящих событий
таки любой, или таки с заданным в документации пределом
>> Любая ОС становится ОС реального времени.
>только денег на ней на этом рынке можно заработать не более нуля.Я же сказал - чистой воды маркетинг.
>> при любой интенсивности входящих событий
>таки любой, или таки с заданным в документации пределомЕсли в документации оговорен предел, то надо искать соответствующие этому пределу вычислительные средства (плюс "ефрейторский зазор", естественно), а не мудрить с жестким или не очень жестким реальным временем. Либо в корне пересматривать решение задачи и... обходиться БЕЗ операционной системы.
Ценность патчей никто не принижает - грамотный планировщик - всегда хорошо. Но и преувеличивать их не стоит. Лучше поиметь запас вычислительной мощности и систему "нереального" времени, чем четко укладываться в рамки задачи. Я только об этом.
>Таким образм все разговоры о "реальном времени", а особенно "жестком реальном времени" в действительности обычный маркетинг. Реальное отличие таких ОС от остальных - сильно сокращенное время реакции на события (читай быстрое переключение контекстов), что позволяет в пиках загрузки успевать отработать большее их количество.Не может быть в "чистом виде" ОС реального времени без учета приложений и аппаратуры. ОС считается real-time если она обеспечивает механизмы, позволяющие строить системы реального времени (именно системы, то есть, всё вместе - приложения+ОС+платформа). И, естественно, все это сильно специфично для конкретной задачи. Рассматривать теоретический "жесткий" real-time невозможно - он никогда не будет достигнут (это будет то о чем вы говорили - "потому как в любом случае повышая интенсивность возникновения событий мы любую систему ставим раком").
Простой пример: есть система (ОС+приложения+железо), обрабатывающая звуковой поток с определенным битрейтом при этом есть какие-то задачи управления, поддержка сети, веб-сервер и т.п. Все работает - работа звукового тракта фиксирована и не зависит ни от интенсивности поступления команд управления, ни от активности сети ни от... Для этого от ОС нужно только одно - если есть данные для потока, обрабатывающего звук - он должен выполняться независимо от того сколько он уже выполняется и сколько данных скопилось для обработки другим потокам, какой поток выполнялся до этого и что он делал, т. к. это основная задача и у нее высший приоритет (конкретная реализация этого может быть самая разная: вытеснение задач ядра, вложенные прерывания - тысячи способов и уловок). Естественно, вся система должна быть спроектирована так, чтобы в среднем(!) всем хватало ресурсов (это задача именно системного уровня, а не только ОС), но если что, в жертву, приносятся задачи строго в соответствии с приоритетом. Это система реального времени и, если в разы превысить, например, битрейт, так, что система начнет "лажать" это не означает, что система и не реального времени вовсе - просто прилагательное real-time без учета системы целиком и условий эксплуатации не имеет практического смысла (только теоретико-философский).
Формальные определения оперируют понятиями типа "время реакции на события" - без учета системы в целом это классический "сферический конь в вакууме", поэтому единственный правильный ответ на вопрос "А какое у вас время реакции на события?" - это "it depends...".Планировщики задач ОС общего назначения исходят из принципа (упрощенно) "если у одной активной задачи низкий приоритет - она выполняется меньше тех, у которых приоритет выше". В мире real-time - "если есть активная задача высокого приоритета, то, пока она остается активной задачи более низкого приоритета НЕ ВЫПОЛНЯЮТСЯ совсем". А это значит, что если запускать задачи, не учитывающие этот факт, то система в целом будет неработоспособна. Это одна из основных причин, почему в десктопных и серверных ОС не делают планировщики реального времени.
>>Таким образм все разговоры о "реальном времени", а особенно "жестком реальном времени" в действительности обычный маркетинг. Реальное отличие таких ОС от остальных - сильно сокращенное время реакции на события (читай быстрое переключение контекстов), что позволяет в пиках загрузки успевать отработать большее их количество.
>
>Не может быть в "чистом виде" ОС реального времени без учета приложений
>и аппаратуры.Фиг вам
>>>Таким образм все разговоры о "реальном времени", а особенно "жестком реальном времени" в действительности обычный маркетинг. Реальное отличие таких ОС от остальных - сильно сокращенное время реакции на события (читай быстрое переключение контекстов), что позволяет в пиках загрузки успевать отработать большее их количество.
>>
>>Не может быть в "чистом виде" ОС реального времени без учета приложений
>>и аппаратуры.
>
>Все расписанное - полный бред 30 летней давности, меняйте ваших преподавателей и
>учебники.
>Может приведете пример ОС, которая сумеет обеспечить работу системы в "реальном времени" независимо от приложений, требований к системе и задач возлагаемых на эту систему (не говоря уже об аппаратной платформе)?
Переходите уже от учебников и преподавателей к реальности. В жизни все не совсем так как в книжках.
классически хард риалтайм - это когда невыполнение гарантии ведет к катастрофе.
Софт риалтайм подразумевает допущение невыполнения , с последующим восстановлением.
> классически хард риалтайм - это когда невыполнение гарантии ведет к катастрофе.
> Софт риалтайм подразумевает допущение невыполнения , с последующим восстановлением.да никто не заприщает называть WinXP-Home мягким RTOS'ом, но пользователям от этого не легче.
видел я проекты "реального времни", под десктопные ОСи. более того, они даже какое-то время успешно работали. теперь все ОСи называть мягкими RTOS'ами?
>да никто не заприщает называть WinXP-Home мягким RTOS'ом, но пользователям от этого
>не легче.Такой мягкий немецкий РТОС, "я я дас ист фантастиш" :)
>If an old kernel package installed, remove it.
># dpkg -r linux-image-2.6.32-art
>Intall the ART-Linux 2.6 kernel package.
># dpkg -i linux-image-2.6.32-art_20100906_i386.debСуровые перцы, "мы не презнаём граб-меню"? =)
А если свет вдруг моргнёт после первой команды? ))
>>If an old kernel package installed, remove it.
>># dpkg -r linux-image-2.6.32-art
>>Intall the ART-Linux 2.6 kernel package.
>># dpkg -i linux-image-2.6.32-art_20100906_i386.deb
>
>Суровые перцы, "мы не презнаём граб-меню"? =)
>А если свет вдруг моргнёт после первой команды? ))LiveCD, chroot, apt-get install ядро... =)
Мужики глобальный облом!#ifdef CONFIG_X86_32
ТОГДА РАБОТАЕТ
#else
НАХ...
#endif
xD
И ещё# make ARCH=i386
...
...
init/built-in.o: In function `kernel_init':
main.c:(.init.text+0x619): undefined reference to `populate_rootfs_domain'
kernel/built-in.o: In function `__art_dispatch':
(.text+0x226a8): undefined reference to `art_trace'
make: *** [.tmp_vmlinux1] Ошибка 1
А какое отношение ART Linux имеет к проекту https://rt.wiki.kernel.org/ ? В ART Linux патчат ядро -rt ?
>А какое отношение ART Linux имеет к проекту https://rt.wiki.kernel.org/ ?Никакого.
> В ART Linux патчат ядро -rt ?Нет, все своё с нуля. Это же япошки.
>все своё с нуля. Это же япошкиПлохо ты знаешь япошек
>>все своё с нуля. Это же япошки
>
>Плохо ты знаешь япошекВ отличии от всего мира, который ПиаРится за счёт судебных нападок со стороны FSF.
Япошки хорошо прячут код, и тихо, мирно юзают. А на публику выставляют только своё.
Так это конкурирующие проекты? Мама дорогая... Их же как грязи теперь... RT-Linux, ART Linux, KURT, Xenomai, RTAI...
И всё разные...
%))) есть реальное, есть реально жесткое и наверное скоро будет мега-реально жесткое:)))
А есть и "Мягкий" реал-тайм ;)
>%))) есть реальное, есть реально жесткое и наверное скоро будет мега-реально жесткое:)))
>Тру жесткое)
Реально суровое время =)
пацанское
Систем жёсткого реального времени не существует. Откройте учебник по ОСРВ или системному программированию. Учиться никого не поздно, а пофлудить всегда успеете.Кстати о "RT-Linux, ART Linux, KURT, Xenomai, RTAI... ", под каждую задачу пилят своё ядро, чтобы эта задача выполнялась успешно, благо открытость позволяет.
>Систем жёсткого реального времени не существует. Откройте учебник по ОСРВ или системному
>программированию. Учиться никого не поздно, а пофлудить всегда успеете.
>
>Кстати о "RT-Linux, ART Linux, KURT, Xenomai, RTAI... ", под каждую задачу
>пилят своё ядро, чтобы эта задача выполнялась успешно, благо открытость позволяет.
>Такой учебник, значит. Вот ссылочка - учиться никогда не поздно ;-) Там различия soft и hard realtime вполне толково расписаны.
>Систем жёсткого реального времени не существует. Откройте учебник по ОСРВ или системному
>программированию.В соответствии с формальными определениями, ОС "жесткого" реального времени не только не существует, но и не может существовать. Ни одна ОС сама по себе (без учета запускаемых приложений, железа и решаемых задач) никогда не сможет обеспечить работу системы в реальном времени. Чтоб можно было громко заявлять про real-time какого-либо одного компонента системы (чаще всего ОС - чистый маркетинг) без учета остальных, придуман термин "мягкого" реального времени. Это как отказ от ответственности: "Мы поставляем высоконадежные системы, которые помогут вам бла-бла-бла", а чуть ниже мелким шрифтом "мы не несем никакой ответственности за возможные....". Типа как: у нас рилтайм, но иногда так себе рилтайм, а бывает и совсем не рилтайм.
>Типа как: у нас рилтайм, но иногда так себе рилтайм, а бывает и совсем не рилтайм.великолепно =)))
Слишком однообразные названия . Лучше бы Аист-Линуксом назвали , в честь фирмы . Аист , порождённый пингвином , это звучит гордо !
Заработало!!! Под VMware правда. Реалтайм не заметил!!!