Ну, раз флудить, так флудить...
Чтобы сделать что-то лучшее, нужны желание и возможность. Они есть?
Еще толком не определились, что действительно следует улучшать, но уже захотели притянуть поддержку старых приложений и т.п. Так не пойдет! Может лучше наоборот начать с того, чтобы к имеющейся системе добавить абсолютно новый набор системных вызовов, который бы пока опирался в том числе и на старый набор, причем "особые" группы системных вызовов (графику, взаимодействие с устройствами на основе физической адресации, взаимодействие с конкретными видами ФС и т.п.) сразу оформить в виде независимых наборов сервисных функций, которые бы не относились непосредственно к ядру. Короче нужно идти не по пути расширения интерфейса ядра, а по пути добавления к ядру новых интерфейсов посредством существующего интерфейса ядра. Я использую многоуровневую систему введения новых интерфейсов. Прежде всего это серверы - ПО, предоставлющее совершенно независимые от ядра наборы сервисных функций, доступные в том числе и приложениям. Обращение реализовано через трап-шлюзы IDT - не слишком удачный вариант с точки зрения современной тенденции иметь одну точку естественного входа в пространство ядра, с чем я в общем-то согласен, но это было сделано еще в то время, когда сиколы/сисэнтеры мягко говоря были не очень популярны в отличии от интов. Я грезил добавлением подсистемы Линукс через int 80h к моему int 60h. В принципе серверы можно реализовать и без использования трап-шлюзов. Просто главный принцип моих серверов здесь выражен абсолютно четко - добавление нового интерфейса через стандартный для него номер (именно номер, а не имя), просто 0-5Fh у меня зарезервированы для системных нужд (можно сказать, что и 60h тоже, хотя по сути это просто уже установленная точка входа в "сервер ядра"). Еще один уровень - это наш незабвенный IOCTL - набор функций (виртуальных) устройств, в котором зачастую для одной и той же функции разных устройств имеются различия не только в ее назначении, но и в наборе ее параметров. Сейчас IOCTL у меня реализован как набор из 8 последовательных системных функций DeviceIO0-7, которые транслируются ядром в нереентерабельные функции устройств 0-7 через структуры, описывающие эти устройства. Есть идея расширить набор этих функций до 16 (добавив либо еще одну группу DeviceIO8-15, либо новую группу DeviceIO0-15). Хотя в принципе можно иметь одну единственную функцию DeviceIO и передавать номер функции устройства как отдельный параметр, тогда количество функций у устройств может быть практически неограниченным. DeviceIO0-7 доступны в том числе и приложениям, если устройства не заблокированы управляющими структурами (это что-то типа монтирования, см. далее). Open/Close-механизм для устройств у меня не используется - это такая фишка - устройство либо само заботится о своем единоличном использовании, либо захватывается управляющей структурой, либо его функции остаются транзакционными и доступными сразу нескольким клиентам. Последний уровень - это уровень управляющих структур, через который в систему могут быть добавлены не только новые интерфейсы, но и структуры нового формата, которыми частично может управлять ядро. Управляющие структуры позволяют задействовать максимально абстрактный уровень управления, но в принципе они завязаны на виртуальных устройствах (они и называются именно так, потому что позволяют управлять устройствами). Благодаря управляющим структурам, можно вводить новые подсистемы ядра и даже подсистемы, локализованные вне ядра, с закрытыми внутренними интерфейсами, доступными только этим подсистемам. Фактически управляющие структуры позволяют регистрировать новые внутренние интерфейсы одним сторонним ПО для другого стороннего ПО. Чтобы было понятно, о чем идет речь, скажу несколько слов о подсистемах ядра, использующих управляющие структуры. Сейчас таких подсистем две: консольная и файловая (VFS, включая своп). Консольная подситема использует управляющие структуры, описывающие физические консоли (пока подсистемой поддерживается единственная физическая консоль с одним устройством отображения), предоставляя одну виртуальную консоль каждому процессу ее запросившему, а файловая подсистема использует управляющие структуры, описывающие файловые системы, предоставляя файловые функции для работы с единой файловой системой. Драйверы регистрируют управляющие структуры определенного типа, чтобы дать соответствующей подсистеме внутренний интерфейс управления устройствами подходящих типов более высокого уровня (более абстрактный и более универсальный), чем IOCTL-интерфейс самих устройств, с которым работают эти драйверы. А подсистемы могут предоставить единый внешний интерфейс к разным управляющим структурам определенного типа, каждая из которых может быть смонтирована на множестве подходящих по типу и по своей внутренней структуре устройств.
Про неправильно выбранный в настоящее время баланс между разработкой ядра и разработкой приложений я уже говорил здесь ранее. Пусть ядерщики занимаются внутренним строением ядра, а прикладники пока думают, какой сервис ядра им необходим. При этом все имеющиеся и вновь создаваемые приложения автоматически переводятся в разряд тестовых, причем с их помощью тестируется прежде всего ядро, а сами они максимально вылизываются, чтобы не исказить результаты работы ядра на данных тестах.
О коммерческом использовании пока и задумываться не стоит. Если нет продукта, как вы его собираетесь продавать? Если хотите продавать идеи, нужно прикрыть все форточки (лучше уйти в подполье) и искать покупателей. Кстати идеи-то хоть есть, на которые может возникнуть коммерческий спрос? Если получится более-менее качественный продукт, то и сферу его коммерческого применения можно будет найти. Конечно, не завоевать весь мир, но занять определенную нишу вполне реально. Здесь уже можно сделать упор на оригинальных приложениях определенного назначения, а система будет прилагаться к ним в довесок бесплатно или почти бесплатно
, потому что вы не создаете эти приложения под другие программные платформы. Если вдруг кто-то слижет ваш софт, причем так, что не подкопаетесь, вступаете в честную (с вашей стороны) конкурентную борьбу и пытаетесь усовершенствовать ваш софт лучше/быстрее, чем ваши конкуренты.
С ориентацией на определенные аппаратные платформы, типы компьютеров пока все просто: аппаратная платформа на базе процессоров IA-32, Intel/AMD 64 (фасм, генерирующий код для других чипов я пока не встречал, хотя макросредства фасма много чего интересного позволяют сделать
); компьютеры - десктопы, в последствии может и малые серверы на базе все тех же процессоров IA-32, Intel/AMD 64. Говорить про встраиваемые системы, даже на базе процессоров IA-32, Intel/AMD 64, никакого повода пока не вижу, хотя лично у меня мамка с Линухом
IA-32 или исключительно Intel/AMD 64, а может их вообще совместить в одной системе? Как-то вы быстро поспешили в этой ветке отказаться от IA-32, несмотря на то, что KOS продолжает оставаться чисто 32-разрядной системой. Конечно все мы менее критично начинаем смотреть на Intel/AMD 64, хотя, как кто-то здесь сказал, это еще тот костыль (я бы после этого вообще запретил AMD добавлять что-то свое, а лишь следовать тому, что предложит Intel
), но о быстром уходе IA-32 со сцены по прежнему говорить опрометчиво (столько утиля так быстро еще никто не перерабатывал
). Совмещать тоже далеко не самый лучший вариант, несмотря на то, что на уровне приложений это не так уж сложно сделать, как впрочем и прослойку для трансляции 32-разрядных системных вызовов в 64-разрядные при условии, что они между собой похожи. Однако я по прежнему придерживаюсь мнения иметь две линейки системы - чисто 32-разрядную и чисто 64-разрядную. Тем более что если опираться на хорошо спроектированную, а не на быстро скодированную 32-разрядную систему, то на основе 32-разрядного варианта ядра и другого базового ПО в приемлемые сроки можно получить их 64-разрядные аналоги. Конечно, кое-что придется существенно изменить, но в целом 64-разрядная система должна оставаться внешне схожей с ее 32-разрядным прототипом и в частности ядро должно иметь аналогичный набор системных вызовов, работать на основе тех же базовых алгоритмов.
Что касается сопутствующих технологший типа ACPI, PnP, PCI и т.п., то я считаю, что конечно их поддержка важна и нужна, но не следует смещать акценты с базовых аппаратных технологий (процессор и память) и алгоритмов в их пользу.
Ну и несколько слов по поводу микроядра и монолита. Здесь кто-то верно заметил, что нет никаких оснований переходить на микроядро. Микроядро сейчас скорее модный тренд, нежели действительно прогрессивная технология. Масштабируемость, защищенность, стабильность лучше пытаться достичь за счет лучшей структурированности, модульности, более простой и максимально прозрачной реализации, специальных методов защиты и т.п. Как только я пытаюсь представить оригинальное микроядро KOS, написанное с использованием тех же принципов и подходов, которые использовались при написании текущего варианта ядра, мне сразу становится страшно. Компоновка монолитного ядра во время компиляции также является неприемлемым вариантом. Предпочитаю включать в ядро только те драйверы, без которых его функционирование становится действительно проблематичным. Это прежде всего достаточно универсальные драйверы, обеспечивающие простейший ввод-вывод для пользователя, работающие с базовой аппаратурой (процессор и память), использующие полученную от BIOS в реальном режиме информацию (например, те же APM, ACPI), управляющие стандартными для AT-архитектуры онбоард-устройствами, а также современными и не очень шинами (например, главный мост PCI, хотя здесь возможны варианты).
P.S. Думаю, на сегодня хватит
