Сергей, что подвигло Вас на написание собственной ОС? Чего, по Вашему мнению, не хватает таким ОС как RTEMS, eCOS, Fiasco, uCOS-II? Какую характеристику uOS Вы бы назвали приоритетной? Планируется ли реализация в uOS защиты памяти? Будет ли реализована поддержка динамически загружаемых модулей?
Начинал я с разработок на микроконтроллере PIC17C43. Нужны была система, дающая возможность иметь несколько независимых задач. Вытесняемая многозадачность на этой архитектуре не получается - нет возможности переключить стек (как и на 8051). Сделал кооперативную.
Потом был Atmel AVR. В процессе поиска готовой системы для нее набрел на uCOS-II. Она-то меня и вдохновила. Хорошая система, но... корявая. Не было смысла брать ее как есть, проще написать свою. :-)
eCOS слишком громоздкая была для AVR. И потом, они тащат POSIX-совместимость, что, на мой взгляд, есть минус.
Fiasco тогда не было. Вообще, проект L4 нагоняет некоторую тоску. Как бы не получился Multics-2000. :-/
Двигало в основном, конечно, любопытство. Всегда было интересно, как же работают операционные системы. :-) Ну и хотелось проверить другую парадигму. Построить систему не на подходе ядро/системные вызовы, а на потоках/динамическом связывании. Система как набор DLL-лек, которые друг друга вызывают.
На настоящий момент приоритетная характеристика - модульность. Модульная операционка для встроенных применений. Даже драйвер таймера не является необходимым. Как только появится динамическое связывание - будет что-то вроде MSDOS. :-)
Защита памяти будет обязательно. Но потом. Жил же Mac OS аж до 9-й версии без защиты памяти.
Динамически загружаемые модули - это сейчас самое главное. Но для этого хотелось бы дождаться поддержки Ады2005 в GCC.
> они тащат POSIX-совместимость, что, на мой взгляд, есть минус.
Я тоже считаю, что нельзя делать всё ради совместимости с POSIX, но с другой стороны это даёт совместимость с основной массой приложений. Или это цена, которую стоит заплатить?
> Вообще, проект L4 нагоняет некоторую тоску. Как бы не получился Multics-2000. :-/
Почему? Разве плохо, что разработчики прилежно документируют интерфейс ядра? Реализации есть уже на 8 платформах или даже больше.
> Но для этого хотелось бы дождаться поддержки Ады2005 в GCC.
Т.е. планируете переписать ядро на Аде? Aда2005 вроде уже большей частью в GCC реализована. Или есть какая-то нереализованная возможность без которой никак нельзя начать переход? А что будет после перехода с частями, которые сейчас на C? Как планируется стыковать написанное на Аде ядро с библиотеками на C, от которых уйти довольно сложно?
L4 поражает своей универсальностью. И не дает никакой полезной функциональности. Красивость ради красивости?
От GCC требуется реализация интерфейсов Ады2005. Их пока еще нету. Совсем уж переписывать, может, и не надо, просто обеспечить двуязыковость. Стыковать Аду с Си совсем несложно, при определенной самодисциплине.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
uOS
Date: 2005-11-06 23:29 (UTC)Чего, по Вашему мнению, не хватает таким ОС как RTEMS,
eCOS, Fiasco, uCOS-II? Какую характеристику uOS Вы бы
назвали приоритетной?
Планируется ли реализация в uOS защиты памяти?
Будет ли реализована поддержка динамически загружаемых
модулей?
Re: uOS
Date: 2005-11-22 02:18 (UTC)Начинал я с разработок на микроконтроллере PIC17C43. Нужны была система, дающая возможность иметь несколько независимых задач. Вытесняемая многозадачность на этой архитектуре не получается - нет возможности переключить стек (как и на 8051). Сделал кооперативную.
Потом был Atmel AVR. В процессе поиска готовой системы для нее набрел на uCOS-II. Она-то меня и вдохновила. Хорошая система, но... корявая. Не было смысла брать ее как есть, проще написать свою. :-)
eCOS слишком громоздкая была для AVR. И потом, они тащат POSIX-совместимость, что, на мой взгляд, есть минус.
Fiasco тогда не было. Вообще, проект L4 нагоняет некоторую тоску. Как бы не получился Multics-2000. :-/
Двигало в основном, конечно, любопытство. Всегда было интересно, как же работают операционные системы. :-) Ну и хотелось проверить другую парадигму. Построить систему не на подходе ядро/системные вызовы, а на потоках/динамическом связывании. Система как набор DLL-лек, которые друг друга вызывают.
На настоящий момент приоритетная характеристика - модульность. Модульная операционка для встроенных применений. Даже драйвер таймера не является необходимым. Как только появится динамическое связывание - будет что-то вроде MSDOS. :-)
Защита памяти будет обязательно. Но потом. Жил же Mac OS аж до 9-й версии без защиты памяти.
Динамически загружаемые модули - это сейчас самое главное. Но для этого хотелось бы дождаться поддержки Ады2005 в GCC.
Re: uOS
Date: 2005-11-24 23:58 (UTC)Я тоже считаю, что нельзя делать всё ради совместимости с POSIX, но с другой стороны это даёт совместимость с основной массой приложений. Или это цена, которую стоит заплатить?
> Вообще, проект L4 нагоняет некоторую тоску. Как бы не получился Multics-2000. :-/
Почему? Разве плохо, что разработчики прилежно документируют интерфейс ядра? Реализации есть уже на 8 платформах или даже больше.
> Но для этого хотелось бы дождаться поддержки Ады2005 в GCC.
Т.е. планируете переписать ядро на Аде? Aда2005 вроде уже большей частью в GCC реализована. Или есть какая-то нереализованная возможность без которой никак нельзя начать переход? А что будет после перехода с частями, которые сейчас на C? Как планируется стыковать написанное на Аде ядро с библиотеками на C, от которых уйти довольно сложно?
Re: uOS
Date: 2006-01-07 10:12 (UTC)L4 поражает своей универсальностью. И не дает никакой полезной функциональности. Красивость ради красивости?
От GCC требуется реализация интерфейсов Ады2005. Их пока еще нету. Совсем уж переписывать, может, и не надо, просто обеспечить двуязыковость. Стыковать Аду с Си совсем несложно, при определенной самодисциплине.