Разработка концептуально новой ОС

Цитата

В ходе выполнения autoexec загружаются приложения-драйвера, которые "забирают" порты себе.
...
Задача администратора - включить в autoexec все, чтобы перехватить важнейшие устройства.

Дык это тоже получим Linux. Загружаются в автозагрузке модули и встраиваются в систему, занимают ресурсы.

Цитата

Для ядра ВСЕ приложения изначально равноправны, поэтому, кто первый попросит - тому права на порт и будут отданы. После чего порт помечается занятым, и никто больше к нему не допускается.

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

С прерываниями проще.
Реализация. Драйвер требует права на прерывание. Регистрируется. Как только происходит прерывание, посылается сообщение приложению-драйверу.  Тут стоит задуматься о том, собирается ли эта система быть Real Time.

Далее получается событийная система. Задача переключается только если появляется у другой задачи в очереди более приоритетное сообщение.
Приоритеты сообщений. (0-самое приоритетное)
системные сообщения.
0 - Прерывания (учитывая их приоритеты )
16 - планировщик- переключение.
17 - другие системные
...
пользовательские сообщения.
...

Переключение задачи происходит по приоритету сообщения.  Чтоб исключить голодания, переключение еще будет зависеть от таймера + можно учитывать приоритет задачи, сколько она уже работает. Вобщем динамический приоритет.(почти стандарт).
Пока в очереди нет сообщения - задача спит.

Планировщика запускается при появлении в системе нового сообытия-сообщения.

Это самая очевидная реализация системы на сообщениях.

Цитата

Указатели в системе все 6-байтные – включают сегмент.

Сегменты это хорошо. У всех задач будет один сегмент, в смысле номер(при переключении задачи дескриптор перегружается)?

И последнее. Средства программирования. Это будет gcc,g++ или свой концептуально новый компиллятор и язык?

Я не совсем понял, что вы имеете в виду: разрешить _любому_ приложению доступ ко _всем_ I/O-портам и IRQ, которые не заняты другими приложениями?

И вообще, ребята, не серьёзно всё это. Если так всё делать, будет уже куча проблем. Вы ведь хотите, чтобы это работало не только на x86? Тогда вам надо всё делать не так. Вы бы почитали сначала доки по процессорам семейств IA32, IA64, ARM, ALPHA!

Некоторые идеи, на которые стоит обратить внимание.
1. "Безъядерные" системы. Нет строгого разделения между "системой" и "приложениями" -все модули равны.
2. Модульный дизайн. "Приложения" ликвидируются как класс. Программы представляют собой модули aka DLL aka COM-объекты и т.п.
3. Минимальная зависимость от аппаратной защиты. В идеале все выполняется в одном режиме. Программы пишутся на языках высокого уровня со статической проверкой.
4. Динамическая кодогенерация. Нет бинарникам! Только коды виртуальной машины, а еще лучше - семантические деревья.
5. Файловая(ые) система(ы) - просто библиотеки. Например, при разработке СУБД они только мешают.
6. Менеджер памяти на основе сборки мусора.
7. Устойчивые объекты, сохраняющие состояние при вырубании системы.
8. Активные объекты как альтернатива процессам и нитям.

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

Тааак... Тред стал трудно читаемым... Нужно принимать срочные меры ;D

Моё предложение: для такого гарячего обсуждения нужны бюллетени со сводкой или перечнем того, к чему пришли в результате.

2 nvm: запость плз мне на почту файл со сводной спекой, опиши там идеи, включая те, которые уже писал на этом форуме (можно не всё сразу, будешь присылать мне их по мере возникновения новых или изменения старых). Мы тут сделаем подобие CVS (в качестве сервера буду выступать я ;D )

Цитата leemouse, 08.09.03, 16:41:31

Здравствуйте, герои (тот кто решился на разработку новой ОС сейчас - уже герой ;D, независимо от результата)
Имею довольно продолжительный опыт проектирования, разработки и внедрения больших и сложных систем. (сейчас занимаюсь проектом биллинговой системы оператора сотовой связи)
Представляется разумным определиться сначала с так наз. "оргкомитетом" проекта, ответственным за принятие стратегических архитектурных решений. Ибо если проект стартует без должного "устаканивания" основных концепций, архитектуры системы, общих для всех разработчиков идиом и т.д., то он гарантированно умрёт..

Полностью с этим согласен. Ждите, в ближайшем будущем я кое-что предприму в этом направлении

Цитата Trurl, 09.09.03, 10:19:55

Некоторые идеи, на которые стоит обратить внимание.
1. "Безъядерные" системы. Нет строгого разделения между "системой" и "приложениями" -все модули равны.
2. Модульный дизайн. "Приложения" ликвидируются как класс. Программы представляют собой модули aka DLL aka COM-объекты и т.п.
3. Минимальная зависимость от аппаратной защиты. В идеале все выполняется в одном режиме. Программы пишутся на языках высокого уровня со статической проверкой.
4. Динамическая кодогенерация. Нет бинарникам! Только коды виртуальной машины, а еще лучше - семантические деревья.
5. Файловая(ые) система(ы) - просто библиотеки. Например, при разработке СУБД они только мешают.
6. Менеджер памяти на основе сборки мусора.
7. Устойчивые объекты, сохраняющие состояние при вырубании системы.
8. Активные объекты как альтернатива процессам и нитям.

Идеи, бесспорно, интересные, но применимы только в тех случаях, когда они приемлемы для наших целей. Например, что я ожидаю от хорошей ОС?

1. Высокая надёжность, устойчивость к взлому.
2. Высокая производительность. Это значит, что любая задача должна выполняться наиболее эффективно, но при этом удовлетворять моему первому требованию.
3. Простая и удобная архитектура системы. Модульная, объектно-ориентированная, легко расширяемая, она предоставляет приложениям минимум функций, но максимум функциональности. При этом, в архитектуре не должно быть РЕШИТЕЛЬНО НИЧЕГО ЛИШНЕГО (!!!), чтобы не навредить второму требованию.

Поэтому идеи 1, 4, 6 и 8 лично для меня не приемлемы.
А вот на чём бы я сосредоточился - так это на совершенствовании IPC. ИМХО, не надо стараться сделать ОСь, полностью отличающуюся от существующих, но избрать путь эволюции. Очень интересно было бы попробовать применить на практике идею ключей.

Вообще, давайте лучше поговорим пока о том, что нам, собственно важно в новой ОС, сформулируем требования, определимся, где эта ОС может быть применима: для кластеров, SMP, персоналок, КПК или кофемолок? Или это не играет никакой роли, и вы хотите придумать просто ещё одну экзотическую ОСь, коих сейчас великое множество?

Цитата Vilmor, 09.09.03, 11:01:03

Поэтому идеи 1, 4, 6 и 8 лично для меня не приемлемы.

Непонятно, почему?
Сборка мусора повышает надёжность. Конечно, возможно снижение производительности, но здесь не всё ясно.
Отсутствие ядра значительно повышает производительность. Надёжность будет никакая, если не принимать дополнительных мер.
Динамическая кодогенерация - вещь спорная. Система малость усложняется. Производительность может падать, а может и возрастать - всё зависит от соотношения скорость процессора / скорость ввода-вывода. Зато возрастает переносимость, и появляются дополнительные возможности верификации. Для персоналок вполне приемлемо, для серверов?
Активные объекты: Производительность IPC возрастает радикально. Простота и удобство - дальше некуда. Надёжность, опять же .
Итого: если изгнать ассемблер, си &Co или выделить им отдельную песочницу со своим адресным пространством, где-нибудь в 10-м кольце, остальную часть системы можно сделать проще, надёжнее и производительнее.

Цитата

Вообще, давайте лучше поговорим пока о том, что нам, собственно важно в новой ОС, сформулируем требования, определимся, где эта ОС может быть применима: для кластеров, SMP, персоналок, КПК или кофемолок?

А это правильно. С этого всегда надо начинать.

Цитата

Некоторые идеи, на которые стоит обратить внимание.
1. "Безъядерные" системы. Нет строгого разделения между "системой" и "приложениями" -все модули равны.
2. Модульный дизайн. "Приложения" ликвидируются как класс. Программы представляют собой модули aka DLL aka COM-объекты и т.п.  
3. Минимальная зависимость от аппаратной защиты. В идеале все выполняется в одном режиме. Программы пишутся на языках высокого уровня со статической проверкой.
4. Динамическая кодогенерация. Нет бинарникам! Только коды виртуальной машины, а еще лучше - семантические деревья.
5. Файловая(ые) система(ы) - просто библиотеки. Например, при разработке СУБД они только мешают.
6. Менеджер памяти на основе сборки мусора.
7. Устойчивые объекты, сохраняющие состояние при вырубании системы.  
8. Активные объекты как альтернатива процессам и нитям.  

1) По предложенной nvm архитектуре это получается.
2) Все программы всегда представляют собой  объекты - DLL,COM. Как будут дергаться интерфейсы? Может нужно только для GUI.
4) О виртуальной машине. Всегда всем хотелось свободы. Поэтому надо сказать да и бинарникам, и виртуальной машине. Ядро само поймет как какое приложение исполнять. (Можно просто сделать модули поддержки разных испольняемых форматов)
Для офисных приложений - виртуальная машина, для серверов  производительность критична, перекомпиляция на страшна - лучше бинарники.
5) Это точно должно быть.
6) Сборщик мусора... В виртуальной машине хорошо. В бинарнике (ядро тоже бинарное) - не получится. Да и сборка мусора произойдет при удалении адресного пространства приложения.
7) Т.е. машина возобновляет работу на том же месте, где остановилась?
8)"Активные объекты как альтернатива процессам". Поясните!

В итоге получается система из объектов с мноооожественным наследованием всего. (аналогия с другими ОС - приложение+ загрузка динамических библиотек).

А требование к ОСи. Персоналка + SMP(хотя бы потому, что большинство разработчиков не будут иметь доступ к "кофемолкам"), многозадачность...

Сообщение отредактировано: rcz - 09.09.03, 10:43

Цитата Trurl, 09.09.03, 13:50:28

Непонятно, почему?
Сборка мусора повышает надёжность. Конечно, возможно снижение производительности, но здесь не всё ясно.

Дело в том, что сборка мусора - вещь весьма трудоёмкая. Если у вас тысячи объектов и сотни тысяч ссылок, то это выливается уже в большую проблему. А если ссылки могут образовывать циклы, то простым счётчиком AddRef/Release не отделаешься. Потребуется каждый раз проходить по всем объектам и ссылкам, т.е. полный перебор, линейная трудоёмкость... Существуют, конечно, модифицированные, улучшенные алгоритмы (двухпроходной, например), но и это не улучшает ситуацию кардинальным образом.

Более того, сборка мусора для реальных задач может быть и не нужна. Тут, как говорится, "из пушки по воробъям". С другой стороны, она бы отнимала время в приложениях, где критично время. Кроме того, ОС, которая навязывает использование сборщика мусора, не м. считаться real-time OS, т.е. не м. быть использована для целого класса задач.

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

Цитата Trurl, 09.09.03, 13:50:28

Отсутствие ядра значительно повышает производительность. Надёжность будет никакая, если не принимать дополнительных мер.

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

Цитата Trurl, 09.09.03, 13:50:28

Динамическая кодогенерация - вещь спорная. Система малость усложняется. Производительность может падать, а может и возрастать - всё зависит от соотношения скорость процессора / скорость ввода-вывода. Зато возрастает переносимость, и появляются дополнительные возможности верификации. Для персоналок вполне приемлемо, для серверов?

Вы имеете в виду Just-In-Time (JIT) компиляцию? Это как в .NET? Да, это хорошая вещь для интерпретируемых языков. Если простой интерпретатор выполняет программу раз в 20-30 медленнее аналога на Си, то JIT-машина делает это только в 2-3 раза медленнее, но всё же это слишком, чтобы всю ОС переводить на JIT.

И такое решение не годится для карманных компьютеров (КПК), встроенных систем, сотовых, кофеварок. Да и для персоналок это может стать приемлемым решением не так скоро. Системное ПО, real-time приложения в любом случае не могут себе это позволить.

Вывод: опять, же, переносим это из ядра в пользовательский процесс, на более нижний уровень привилегий.

Цитата Trurl, 09.09.03, 13:50:28

Активные объекты: Производительность IPC возрастает радикально. Простота и удобство - дальше некуда. Надёжность, опять же .

Наверное, я просто не вкурсе этого вопроса. Где можно прочитать что-то конкретное про Active Objects? Сайт http://bluebottle.ethz.ch в этом отношении мне показался совершенно не информативным. Было бы интересно узнать, какие при этом накладные расходы, и вообще узнать бы побольше об этой технологии...

Цитата Trurl, 09.09.03, 13:50:28

Итого: если изгнать ассемблер, си &Co или выделить им отдельную песочницу со своим адресным пространством, где-нибудь в 10-м кольце, остальную часть системы можно сделать проще, надёжнее и производительнее.

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

Кстати, кольца есть опять же только на x86. Конечно, на др. процах есть их аналоги, но не прямые. Во всяком случае, м. рассчитывать только на 2 "кольца" – кольцо для ядра ОС и кольцо для приложений.

Цитата Trurl, 09.09.03, 13:50:28

А это правильно. С этого всегда надо начинать.

Начну-ка...

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

1. Если надо обратиться к привелегированному объекту, используются syscallы
2. Если объекты в одном процессе, то через простой вызов ф-ции.
3. Если в разных процессах, то через некое подобие unix-сокетов.

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

Единая файловая система предоставляет общее пространство имён и образует иерархию, в которой могут быть не только файлы и каталоги, но и объекты синхронихации, объекты и атомарные единицы данных (последние аналогичны Windows Registry). К примеру, pid-файл (точнее, его аналог) для объекта mysqld – это как семафор этого объекта, так и глобальный handle для доступа к интерфейсу объекта mysqld. Мы можем попробовать создать новый mysqld, если его ещё нет, чтобы с ним работать:

OpenObject("/classes/mysqld", "/services/mysqld.pid", CREATE_IF_NOT_EXISTS);

Взаимодействие с объектами идёт через handle, которые играют роль ссылок на объекты. Их можно копировать в др. процессы, но только если они допускают это.

Стоит заметить, что здесь под ФС следует понимать не как способ хронения данных, а как унифицированный интерфейс для работы с различными типами ФС: ext3fs, ntfs, vfat.

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

Цитата rcz, 09.09.03, 14:42:18

А требование к ОСи. Персоналка + SMP(хотя бы потому, что большинство разработчиков не будут иметь доступ к "кофемолкам"), многозадачность...

А я вот имею некоторый доступ к КПК. На рабочем столе стоит один такой. Я для него на асме и C++ программлю, в основном, связанное с MPEG4. Процессор, кстати, RISC-овый, ОС – WinCE 3.0. А в отделе железячников есть специальная борда для удобной отладки ОСей, которая позволяет перепрошивать флэшку. Только борда эта не про нашу честь

Я это к тому говорю, что если кто-то из вас собирается выбивать какое-либо финансирование, то борду такую можно и самим купить.
Конечно, это пока что из области фантазий, но я не вижу причин не предусмотреть заранее поддержку КПК.

Кхе-кхе... Ну кто же занимается подготовкой проекта в ФОРУМЕ. Хотя бы конфу какую нить зарегили штоли. А ещё лучше отдельный сайт с чатом, CVS - репозитарием и т.д. Определиться наконец с составом оргкомитета и выложить хотя бы базовые соглашения и протоколы.

Цитата leemouse, 09.09.03, 16:15:38

Кхе-кхе... Ну кто же занимается подготовкой проекта в ФОРУМЕ. Хотя бы конфу какую нить зарегили штоли. А ещё лучше отдельный сайт с чатом, CVS - репозитарием и т.д. Определиться наконец с составом оргкомитета и выложить хотя бы базовые соглашения и протоколы.

Пока что конфы нет, так что обсуждаем здесь.

А вообще-то, интересно, за что может отвечать оргкомитет, и кто войдёт в его состав... есть желающие?

Итого. Что я вижу в этой оси
ОСь.
1)Микроядерная
2)Все объекты.
3)Порождающийся процесс - требует интерфейсы у других объектов и предоставляет свой.
4) Взаимодействие через сообщения. О сообщениях и многозадачности  что-то писал выше.
5) Драйвер - объект становящийся в очередь сообщений аппаратных ресурсов, системы ввода/вывода, от которых получает сообщения(прерывания и т.п). Для работы с портами, лучше всего сделать драйвера-объекты уровня ядра.
6) ФС, как и все, объектное. Динамически подгружаемое. Точки монтирование - в конфиге.
7) Система имен объектов и HANDLы описаны nvm.

Оргкомитет... Пока тут учавствовало только 4 -5  чел. Будут разрабатывать - ? Желающие в оргкомитет... (все, кто будет разраьатывать ?).
Координатор - leemouse.
И надо бы выяснить, кто будет разрабатывать. И найти дом.

Сообщение отредактировано: rcz - 09.09.03, 13:12