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

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

Вообще-то использовать MMU в сочетании со свопингом не обязательно, а именно это дает непредсказуемые задержки.

...

Чтобы не наступать на грабли Вирта (изоляционизма), нам надо будет идти на компромиссы. В частности, это касается ключевых вопросов:
1. модель адресного пространства (защищенное и единое)
2. сосуществование надежных и ненадежных языков (равноправие или привилегии).

При этом хочется понять, какие возможны компромиссные (комбинированные) решения в обоих вопросах.

...



Если известны приоритеты всех процессов, то что мешает организовать своппинг только для данных и модулей программ, которые относятся к процессам с низшими приоритетами? И волки будут сыты (задачи реального времени будут решаться в реальном времени), и овцы целы (оперативная память не будет переполняться данными фоновых задач и временно не используемыми модулями).


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

Я бы предложил классифицировать задачи по следующим четырем критериям (с примерами в скобках):
1. реального времени (автоматическое управление транспортом) - с разбивкой задач по приоритетам или общего назначения (GUI)
2. требующие высокой надежности (управление самолетом) или допускающие отказы (видеоигры)
3. с небольшим потоком данных (телеметрия) или с большим потоком данных (потоковое видео)
4. с минимальными ресурсами (гаджеты - ограничения по объему, массе и стоимости; сети конроллеров в автомобилях и встроенные системы для бытовой техники - ограничения по стоимости), с большими ресурсами (бортовые компьютеры спутников и самолетов - ограничения по массе) или с неограниченными ресурсами (серверы, персоналки)

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

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

Ответ на »сообщение 2225« (Eeyore)
___________________________
Есть для обсуждения некоторые решения, например, software isolated process (SIP) в подходах Microsoft Research (в частности, в Singularity). Одна из работ на эту тему: "Deconstructing Process Isolation" (2006) http://research.microsoft.com/research/pubs/view.aspx?type=technical%20report&id=1087

Намеренно просмотрел раздел References. НИ ОДНОЙ ссылки на швейцарцев, хотя очевидно, что идеи Singularity перекликаются в первую очередь с Оберонами, а уже во вторую - с разными экзотическими версиями Юниксов и "модульных ассмеблеров", на кои в основном приводятся ссылки... Что "не знают" - не поверим, зная, сколько людей из Цюриха работает в MS Research.

Одно слово - заразы... Но с них-то что взять... А вот у нас: сколько "кулхацкеров" от Блуботла нос воротили - "Это несерьеёзно, защита на уровне языка, общее адресное пространство..." Зато год-два - и начнут превозносить Microsoft как первооткрывателя "новых технологий". И ещё тыкать нас же носом: "Вот, посмотрите, передовые системы..."

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

Тогда к моменту зрелости фундамента, способного к адаптации и перенацеливанию (в том числе на универсальную ОС массового использования) будут на руках проработки соответствующей "насадки".

Раз тут регулярно всплывает автомобильная тема, приведу такую аналогию.

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

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

Ответ на »сообщение 2222« (Димыч)
___________________________

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

Пока в отношении необходимости полноценной (а не частичной, как в Minix) реализации POSIX внутри команды наблюдается определенное единство. Вполне вероятно, что будут еще высказаны и аргументы против (и не только с точки зрения трудоемкости -- это вполне решаемый вопрос). Но пока ситуация именно такова. POSIX планируем реализовывать.

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

Разве мог молодой студент предположить, что его операционную систему, поделку just for fun, придется портировать на другой процессор?

Молодой студент? Вполне мог это делать по-другому. Особенно с учетом всех славословий в его адрес и всевозможных начисленных ему регалий. Плохо, что молодому поколению дают именно такой ориентир-образец для подражания в программировании.

Даже сам Бил Гейт сказал про себя и свою компанию - "Мы не провидцы, но приспособленцы".

Они не приспособленцы, они "проходимцы", но, разумеется, весьма неглупые.

По-видимому, единственно правильный способ разработки  программ и систем - эволюционный.

Эволюционирование подразумевает постепенное развитие, отталкиваясь от некоей отправной точки. Я не сторонник революций, в том числе и в программировании, скорее, "постепеновец" (в терминологии Д.И.Менделеева), но вот с отправной точкой сложилась напряженка. Плясать что от Windows, что от UNIX -- мягко говоря, нехорошо. Вот и приходится думать, анализировать и созидать нечто иное. Не методом Торвальдса. И не методом Гейтса. Но так, чтобы не остаться в итоге на необитаемом острове.

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

Т.е., нужен ДРАЙВЕР ВНИМАНИЯ ПОЛЬЗОВАТЕЛЯ.

Интересная мысль.

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

К чему это я? Если кто-то чувствует в себе силы (и желание) целенаправленно обдумывать, обсуждать и прорабатывать это внутри нашей команды -- милости просим войти в состав участников. Пока соответствующие сектора группы пустуют.

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

Вообще-то использовать MMU в сочетании со свопингом не обязательно, а именно это дает непредсказуемые задержки.

Вопрос: а нужен ли свопинг вообще? :)

Мнение Вирта и Гуткнехта мы принимаем во внимание, но не более. Должна быть своя голова на плечах. :)

В отношении MMU: есть радикальный подход -- не рассматривать процессорные архитектуры без MMU. А есть и вариант совмещения -- попытки усидеть на двух стульях.

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

Чтобы не наступать на грабли Вирта (изоляционизма), нам надо будет идти на компромиссы. В частности, это касается ключевых вопросов:
1. модель адресного пространства (защищенное и единое)
2. сосуществование надежных и ненадежных языков (равноправие или привилегии).

При этом хочется понять, какие возможны компромиссные (комбинированные) решения в обоих вопросах.

Есть для обсуждения некоторые решения, например, software isolated process (SIP) в подходах Microsoft Research (в частности, в Singularity). Одна из работ на эту тему: "Deconstructing Process Isolation" (2006) http://research.microsoft.com/research/pubs/view.aspx?type=technical%20report&id=1087

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


Например, приводилась довольно радикальная точка зрения Вирта и Гуткнехта: "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)


Вообще-то использовать MMU в сочетании со свопингом не обязательно, а именно это дает непредсказуемые задержки. Никто не мешает применять страничную организацию памяти просто для изоляции процессов друг от друга. Задержки при этом также будут различаться в зависимости от попадания/промаха в TLB, но будут куда меньше. Более того, даже в ОС с единым адресным пространством MMU может применяться, например, для организации барьеров, которые так нужны многим продвинутым алгоритмам сборки мусора.

Наконец, никто не мешает память, которая требуется для части системы, работающей в реальном времени, объявить невытесняемой на диск.

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

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

В моем понимании микроконтроллер - это просто микросхема "всё в одном" - процессор, периферия и память.

Скорее всего, вы имеете ввиду, так называемую System-On-Chip, потому что у микроконтроллеров ресурсы ограниченны для такого применения (для управления автомобилями). (Кстати, большинство автомобилей работает под управлением Windows, правда доработанной).
А для операционной системы "система на чипе" выглядит обыкновенным компьютером, и никакой специальной доводки не надо.



То, что некоторые некритичные системы автомобилей работают под Windows, не означает, что "большинство автомобилей работает под управлением Windows, правда доработанной".

См. ссылку Operating systems for Automobiles, посвященную спецификации OSEK/VDX 2.2.1 specification (16-01-2003)для автомобильных ОС:
http://www.operating-system.org/betriebssystem/_english/bs-other.htm
Правда, эта спецификация рассчитана на устаревающий протокол CAN, а не на самый современный FlexRay.

Описание на русском языке: http://citforum.ru/operating_systems/rtos/16.shtml

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