OSDev

Удивительным кажется тот факт, что процесс разработки альтернативных операционных систем самый что ни на есть не систематизированный. Вместо постановки главных вопросов о функционировании и целевом назначении будущей системы, начинающие осеписари начинают с загрузчиков, многозадачности и страничной адресации. В итоге система превращается в нарост на механизмах, а отсутствие какой либо целевой идеи вместе с отсутствием внятной документации рождают очередную многозадачную xOS для ПК с возможностью загрузки и завершения, в которой никто не хочет разбираться. Напротив, чёткое следование логике проектирования "сверху вниз" позволило бы избежать лишних сущностей и разного рода "не стыковок" в системных механизмах. К тому же разумно начинать разработку системы с постановки вопроса о её конечном назначении, а не с изучения ассемблера целевой платформы. Ведь врядли конечного пользователя должен радовать один только факт потрясающей воображение пересылки числа в регистр АХ, при запрещённых прерываниях или ещё что... Т.е. исходные коды, загрузчики и страницы памяти - это то, что должно появиться в самом конце, а не в начале разработки системы... А по мере приближения к железу многие механизмы могут оказаться просто не нужны. Такой подход носит название "поиск с возвратом". Из Википедии:

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

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

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

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

Это только в теории, а напрактике нет.

Не намного. Тем более есть экспресс и оперативная компиляция.

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

Вообще-то этого материала хватает. Вот практики не всем хватает. Да и откуда она возьмётся? Надо выполнить 2-4 проекта чтобы говорить о граммотном проектирование. То есть нужен ведущий инженер который уже прошёл этапы проектирования не одного проекта.

О необходимости сначала думать, а потом делать на этом конкретном форуме я писал чуть ли не пять лет назад: http://osdev.ru/viewtopic.php?f=5&t=165. Ну а почему основная масса не проектирует, а кодирует, догадаться, в общем-то, несложно. Проектирование, а тем более документирование -- достаточно тяжёлый труд, не приносящий внешних результатов. Большинство же хочет получить видимые результаты своих трудов как можно быстрей -- и получает в виде "HelloWorldOS". Ну а когда дело доходит до чего-то более серьёзного, осеписательство обычно либо вообще прекращается, либо приводит к сплошным костылям, с помощью которых мучительно пытаются решать возникающие по ходу дела проблемы, коих было бы в разы меньше, если б сначала подумали (и изучили то, что уже сделано другими), а потом бы лепили. Пример -- КолибриОС.

Кстати, демонстрацией этого принципа является и Линух. По сути, это огромная свалка дерьма, которую уже не раз переписывали чуть ли не целиком (чего стоит одна эпопея с добавлением поддержки SMP). Причина -- отсутствие проектирования. Но система эта всё-таки работает и может применяться для решения целой кучи задач (и вполне себе успешно применяется, как мы знаем). Причина -- опять-таки в проектировании, а точнее, в том, что ЛТ не пытался сделать систему совсем с нуля, а скоммуниздил "проект верхнего уровня" -- описание АПИ от уже знакомого ему Униха. Сидеть и реализовывать вызов за вызовом по уже готовому описанию функций этих вызовов куда проще, чем вообще не иметь подобного описания и выдумывать вызовы по мере необходимости и в соответствии со степенью собственного идиотизма (кстати, пример абсолютно идиотского АПИ -- это уже упоминавшаяся Колибри, а точней, ещё Менуэт, от которого она отпочковалась, унаследовав заодно все его глупости).

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



Чистая, классическая интерпретация медленнее во много раз. Однако современные ВМ работают не как интерпретаторы, а как двойные компиляторы: сначала из исходного языка в промежуточное представление, а потом, уже после запуска программы, из промежуточного -- в машинный код. Поэтому линейные алгоритмы выполняются в общем случае медленнее, чем традиционным образом скомпилированный аналог, а вот циклические могут и пошустрей работать (например, ВМ Жабы от Сан нередко вчистую уделывает ГЦЦ: сановский оптимизатор куда лучше, чем то опенсорцное убожество).



Слишком решительно сказано. О ней никогда забывать не следует, просто не стоит стремиться сразу обеспечить наивысшую производительность. Пример -- всё та же Колибри. Да, написание системы на ассемблере позволяет выжать максимум из процессора (оставим пока вопрос об оптимизирующих компиляторах), но в реале на основной массе современных ЦП не шибко хорошо сделанные в плане эффективности Винда и Линух порвут эту самую Колибри -- хотя б за счёт того, что поддерживают SMP, коей в ней не пахнет и которой не будет без полного переписывания всей системы.



А у опенсорца и другая проблема есть: там же всё добровольно. Это в коммерческой фирме, если тебя взяли быдлокодером, ты должен быдлокодить спущенный сверху проект (который может быть и быдло, и не быдло -- это уж какие архитекторы наверху сидят). А в случае с опенсорцом каждый сам себе хозяин, никакой централизации и т.п. Вот и получается, что мелкие программы, которые по силам сделать одному-двум программистам, нередко превосходят по качеству коммерческие аналоги, а в серьёзных проектах ничего путного, по большому счёту, не выходит. Ну нету сколько-нибудь полноценной открытой замены МС Офису, Фотошопу и прочим адобовским инструментам, САПРам и т.д. и т.п.

Пы.Сы. Под "опенсорцом" я практически всегда понимаю свободно разрабатываемое ПО, а не сам факт открытости исходников. Грубо говоря, если завтра МС откроет все исходники Винды, опенсорцом я это всё равно не назову: как была коммерческая разработка, так и осталась.

pavia
Это только в теории, а напрактике нет.
ActionScript, UCSD p-System, AngelScript, Smalltalk, Lua, Ruby, Python, Parrot, .NET, PHP, Forth, Erlang, Io, Java, JavaScript... Немного практики.. Список продолжать?
Не намного. Тем более есть экспресс и оперативная компиляция.
JIT-компиляция так же уступает традиционным компиляторам в целевой натив.
О производительности надо думать в последнюю очередь. Сначала проектируешь, и делаешь рабочий отлаженный макет, а вот после уже и оптимизацией можно заниматься.
Лучшая оптимизация - высокоуровневая оптимизация. Лучше оптимизируется то, чего можно просто не писать...
Надо выполнить 2-4 проекта чтобы говорить о граммотном проектирование.
Этому, собственно, пост и посвещён. Чтобы выполнить 2-4 проекта, их нужно сначала начать, верно?:)

SII
Думаю, это ключевой момент. Создание ОСи, не подкреплённое реальной жизненной необходимостью, будет держаться на удовлетворении ЧСВ. Ну, написал, допустим HelloWorldOS, показал брату, маме.. Всем понравилось.. Можно браться за проектирование реальной системы:)

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

Всё не верно. Это по тому что у вас опыта и знаний не хватает.

Станислав, гигантов тоже можно понять. Они родились на заре эпохи динозавров, а ещё и в наше время пытаются топ держать. Ну нельзя такие системы взять и переписать. Например, в Линуксе, с каждым годом цена переписывания какого либо бага увеличивается в несколько раз. Если в начале можно было исправить баг за 20$, то теперь он стоит 20.000.000$ Причина, видимо в том, что зависимость кода системы и прикладного ПО однобокая. Т.е. "ядро" системы - это водитель автобуса, который находится под вечным давлением миллиона недоговарившихся пассажиров: налево поверни, направо поверни, возле дерева останови.. То бишь упущена обратная связь в цепи "ядро" - ПО. Возможно, будущие системы будут проектироваться с бОльшим аргументом в пользу гибкости. Но для этого нужно быть немного предсказателем...

Тебе тоже кажется, что за нами кто-то следит?