Ответ на »сообщение 2220« (Сергей Прохоренко)
___________________________

Одна ссылка не пропечаталась:
4. Виртуализация http://www.elecdesign.com/Articles/Index.cfm?AD=1&ArticleID=10813

На сайте radisys.com есть описание системы OS-9.

Мне понравилось The Top Seven Reasons to Choose OS-9:
...
2. Reliability and security: OS-9’s elegant modular architecture and use of processor MMUs protect against memory faults and application errors that crash other RTOSes.
...
5. Standards Compliance: Enhanced portability with support for BSD-Sockets, IPv6 and POSIX Threads. Customers have rapidly ported applications from Linux to OS-9 in days instead of weeks that other RTOS require.

Особенно хочу отметить п.5. Наличие POSIX совместимости, видимо, вещь очень важная для RTOS, уж если это выносится в top seven.

Это еще один аргумент в жарком споре "а надо ли POSIX?.." в пользу "надо!".

Документ с того же сайта http://www.radisys.com/products/OS-9_Selection_Methodology_RTOS_Market.pdf 
дает описание методики оценки систем реального времени.
Можно получить представление о механизме выбора ОС для аэрокосмической отрасли, будущих конкурентах и проблемах ОС реального времени.

Спасибо за ссылки - очень интересный материал!

Одна ссылка не пропечаталась:
4. Виртуализация http://www.elecdesign.com/Articles/Index.cfm?AD=1&ArticleID=10813

Ответ на »сообщение 2216« (Руслан Богатырев)
___________________________

Ответ на »сообщение 2208« (Eeyore)
___________________________

Например, наличие/отсутствие MMU может повлиять на архитектуру

Безусловно, ПОВЛИЯТЬ может.

Если очень упрощенно представлять себе, что архитектура ОС -- это организованная совокупность (абстрактных) значимых элементов (подсистем), а также правила их сосуществования (взаимодействия), то степень влияния тех или иных элементов (подсистем) обусловлена и подходами к абстрагированию. Это абстрагирование рано или поздно имеет дело с конкретикой -- аппаратной архитектурой.

Таймер и аппаратное управление памятью -- важные вещи, от которых просто так отмахнуться, разумеется, нельзя. Именно поэтому внутри нашей группы ведутся столь жаркие дебаты по поводу MMU и потенциальных (целевых) процессорных архитектур.

Например, приводилась довольно радикальная точка зрения Вирта и Гуткнехта: "Its side effects on execution speed are essentially unpredictable. This makes systems with MMU virtually unusable for applications with tight real-time constraints". (Wirth, Gutknecht. Project Oberon. 2005)

На мой взгляд, говоря об абстрагировании ОС от оборудования нельзя бросаться и в другую крайность -- когда для каждой процессорной архитектуры предусматривается своя новая архитектура ОС. Архитектура ОС должна по возможности демпфировать различия целевой аппаратуры, переводя их в плоскость своей реализации. А вот как осуществляется реализация архитектуры ОС, исключительно ли на языке программирования -- это отдельный вопрос, требующий внимательного изучения.



Находки в интернете:

1. Для приложений жесткого реального времени и для приложений общего назначения (например, GUI) могут использоваться разные разделы памяти, различным образом организованные: http://www.radisys.com/products/datasheets/images/os9/dev_kit/os9_devkit_fig02.jpg

2. Взгляд Microsoft на будущее операционных систем: http://www.ctwatch.org/quarterly/articles/2007/02/the-many-core-inflection-point-for-mass-market-computer-systems/

3. eBook - Informations about Operating Systems http://www.operating-system.org/betriebssystem/download/OSDP_eBook_operatingsystems_230707.pdf

4. Виртуализация http://www.elecdesign.com/Articles/Index.cfm?AD=1&ArticleID=10813

5. Виртуализация http://turbovps.com/page.php?8

6. The Philosophy of Neutrino http://rdimitr.chat.ru/qnxarch/intro.html

7. Важнейшим из ресурсов, распределением которого должна заниматься ОС, является внимание пользователя к тем или иным темам, задачам, приложениям, документам, жанрам, страницам, письмам, контактам, видам деятельности, товарам, веб-сервисам, точкам на карте и т.п. http://www.usingattention.com/wp-images/TheAttentionLifeCycle_15083/the-attention-life-cycle.jpg
Т.е., нужен ДРАЙВЕР ВНИМАНИЯ ПОЛЬЗОВАТЕЛЯ.

Это вовсе не шутка. На смену поиску по имени в дереве папок и файлов и поиску по четким критериям (расширение файла, ключевые слова в имени или теле файла, даты создания и последнего изменения и т.п.) должен прийти ассоциативный поиск (например, такой-то документ был создан после просмотра такой-то веб-страницы, и в него была скопирована часть такого-то письма) и GUI с искусственным интеллектом (разумеется, без таких уродств, как «Скрепыш»).

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

Правда, придется крепко подумать о приватности пользователя. Упрятывание документов (и вообще, всех вещей, которые пользовались вниманием пользователя) от постороннего взгляда должно быть реализовано в новой ОС «по умолчанию».

8. Версионность (с возможностью отката к ранее сохраненным версиям), сохранение резервных копий и синхронизация документов в интернете и на флэшках тоже должны поддерживаться на уровне ОС, чтобы не приходилось плодить файлы со слегка различными именами в разных папках.

Ответ на »сообщение 2217« (Руслан Богатырев)
___________________________
А почему? Потому что Линус Торвальдс такими "пустяками" при своей работы над Linux и не озадачивался. Его подход был прост до безобразия -- взять готовую модель (Minix), взять готовый софт (GNU), а затем на новой аппаратуре (x386) начать реализовывать модель с нуля и отслеживать готовность реализации по принципу "задымит -- не задымит". Впрочем, это достаточно подробно описано в его книге Just for Fun: The Story of an Accidental Revolutionary ("Just for Fun. Рассказ нечаянного революционера"). Ну а когда гром грянул, пришлось сильно чесать в репе.
Разве мог молодой студент предположить, что его операционную систему, поделку just for fun, придется портировать на другой процессор?
Даже сам Бил Гейт сказал про себя и свою компанию - "Мы не провидцы, но приспособленцы".
По-видимому, единственно правильный способ разработки  программ и систем - эволюционный. Что не снимает с вас необходимости продумать все заранее, и не совершать ошибки Торвалдса и Гейтса.

Ответ на »сообщение 2214« (Eeyore)
___________________________

Кстати, даже в рамках одной процессорной линейки x86 сколько пришлось изменить в "АРХИТЕКТУРЕ Linux" при адаптации под SMP-системы?

А почему? Потому что Линус Торвальдс такими "пустяками" при своей работы над Linux и не озадачивался. Его подход был прост до безобразия -- взять готовую модель (Minix), взять готовый софт (GNU), а затем на новой аппаратуре (x386) начать реализовывать модель с нуля и отслеживать готовность реализации по принципу "задымит -- не задымит". Впрочем, это достаточно подробно описано в его книге Just for Fun: The Story of an Accidental Revolutionary ("Just for Fun. Рассказ нечаянного революционера"). Ну а когда гром грянул, пришлось сильно чесать в репе.

Ответ на »сообщение 2208« (Eeyore)
___________________________

Например, наличие/отсутствие MMU может повлиять на архитектуру

Безусловно, ПОВЛИЯТЬ может.

Если очень упрощенно представлять себе, что архитектура ОС -- это организованная совокупность (абстрактных) значимых элементов (подсистем), а также правила их сосуществования (взаимодействия), то степень влияния тех или иных элементов (подсистем) обусловлена и подходами к абстрагированию. Это абстрагирование рано или поздно имеет дело с конкретикой -- аппаратной архитектурой.

Таймер и аппаратное управление памятью -- важные вещи, от которых просто так отмахнуться, разумеется, нельзя. Именно поэтому внутри нашей группы ведутся столь жаркие дебаты по поводу MMU и потенциальных (целевых) процессорных архитектур.

Например, приводилась довольно радикальная точка зрения Вирта и Гуткнехта: "Its side effects on execution speed are essentially unpredictable. This makes systems with MMU virtually unusable for applications with tight real-time constraints". (Wirth, Gutknecht. Project Oberon. 2005)

На мой взгляд, говоря об абстрагировании ОС от оборудования нельзя бросаться и в другую крайность -- когда для каждой процессорной архитектуры предусматривается своя новая архитектура ОС. Архитектура ОС должна по возможности демпфировать различия целевой аппаратуры, переводя их в плоскость своей реализации. А вот как осуществляется реализация архитектуры ОС, исключительно ли на языке программирования -- это отдельный вопрос, требующий внимательного изучения.

Ответ на »сообщение 2213« (Илья Ермаков)
___________________________

Ответ на »сообщение 2212« (Сергей Прохоренко)
___________________________

Ответ на »сообщение 2210« (whitetown)
___________________________
Тем более, что возможно применение тройного модульного резервирования, дающего практически 100-процентную отказоустойчивость.

Однако до тех пор, пока там Windows, резервирование от ошибок софта поможет мало :-)
Садиться за руль машины, у которой нет прямой связи между рулём и колесами и педалью тормоза и колодками... зная, что там винда... ох как опрометчиво....

Конечно, ведь одна и та же программная ошибка возникнет в каждом из трех микроконтроллеров.
Поэтому я абсолютно уверен, что между педалью тормоза и тормозными дисками Windows нет. Далеко не на всех контроллерах вообще есть операционная система. Если функции данного микроконтроллера очень узкие, то программа на ассемблере или Си (без плюсов) (редко - на Паскале) жестко зашивается в ПЗУ с помощью программатора - устройства, подсоединенного как к микроконтроллеру, так и к настольному компьютеру. И файловая система в этом случае тоже не нужна - файлов просто нет.

Windows можно использовать только в системах кондиционирования воздуха, навигации, мультимедийных развлечений, противоугонных системах и т.п. А для "управления автомобилем по проводам" нужна надежная ОС жесткого реального времени, или не должно быть вообще никакой ОС.

Ответ на »сообщение 2209« (panda)
___________________________

Лучше расскажите, чем отличается АРХИТЕКТУРА Linux на мейнфрейме и АРХИТЕКТУРА Linux в Nokia 770.


А что, в этой самой Nokia нет MMU? :-)

С точки зрения Unix-подобной системы важна не столько система команд или количество регистров, сколько другие качества архитектуры, например, наличие аппаратной защиты памяти (хотя бы простейшей, вроде разделения памяти на доступную пользовательскому коду/супервизору) или таймерного прерывания для организации вытесняющей многозадачности. По этим (и им подобным) параметрам мейнфрейм на Power и КПК на ARM принципиально не отличаются, поэтому и немудрено, что Linux переносится на них без радикальных изменений. А для сравнения попробуйте прикинуть, как выглядит реализация того же fork() на системах без аппаратного управления памятью (типа 8086). В принципе возможно, но это такое душераздирающее зрелище...

Кстати, даже в рамках одной процессорной линейки x86 сколько пришлось изменить в "АРХИТЕКТУРЕ Linux" при адаптации под SMP-системы?

Ответ на »сообщение 2212« (Сергей Прохоренко)
___________________________

Ответ на »сообщение 2210« (whitetown)
___________________________
Тем более, что возможно применение тройного модульного резервирования, дающего практически 100-процентную отказоустойчивость.

Однако до тех пор, пока там Windows, резервирование от ошибок софта поможет мало :-)
Садиться за руль машины, у которой нет прямой связи между рулём и колесами и педалью тормоза и колодками... зная, что там винда... ох как опрометчиво....