Отправляет email-рассылки с помощью сервиса Sendsay

Создай свою операционную систему!

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Обзор инструментов SEO-оптимизатора и методов продвижения" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

  Май 2004   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Автор
Alexander

Статистика

992 подписчиков
0 за неделю
←   Все выпуски   →

Постановка вопроса


Информационный Канал Subscribe.Ru
Создай свою операционную систему!
Выпуск 1. Постановка вопроса.

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

Ну, ладно, сначала попробую ответить, зачем это нужно. На этот вопрос трудно ответить
односложно. Попробую ответить методом "от противного" :)

Переместимся во времена первых мини-ЭВМ. Для того, чтобы написать какую-нибудь программу, нужно было досконально изучить систему команд ЭВМ, ее архитектуру, затем написать в тетрадке двоичный код программы, и ввести ее в ЭВМ с клавишного регистра.
Следующий этап эволюции:
1) загружаем в ЭВМ с перфоленты текстовый редактор, на электрифицированной печатной машинке набиваем мнемокод программы, выводим результат на перфоленту.
2) загружаем с перфоленты ассемблер, затем загружаем с перфоленты компилируемую программу, выводим на перфоленту результат компилляции.
3) Загружаем с перфоленты отладчик, загружаем с перфоленты отлаживаемую программу, запускаем, находим ошибку, затем повторяем с п. 1. И так сотню раз до получения готовой программы.

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

Итак, "понабив себе шишек", мы решаем сделать программу, которая "сидела" бы в памяти резидентно и предоставляла нам сервисы ввода-вывода, обработки событий и разделения задач. Заодно набрались мужества и реализовали страничную организацию, раз и навсегда.
Сделали, получилось, ура! Теперь разработка программ пошла быстрее. Мы отдаем свой чудо-сервис соседу, а у него несколько другие задачи, с другими требованиями.
Он добавляет в нашу чудо-программу свой сервис, и все начинает идти в кривь и в кось: ведь ему приходится согласовывать свой новый сервис с нашими правилами, которые мы придумывали для себя. В результате и сервисы, конкурирующие за общий порт, начинают зависать, и прерывания "куда-то пропадают", и задачи, конкурирующие за общий ресурс, "зависают" и "падают"...
Далее мы решаем сделать универсальный сервис, который все подчиняет общим правилам и таким образом дает возможность пользоваться им всем желающим, и добавлять туда что-то новое. Прежде чем поделиться с соседом, что же это за правила такие, я позволю себе "лирическое отступление".

Все развивается по спирали! Я прошел всю эволюцию программирования не по книгам, извел кучу тетрадей и перфолент, вместе с Дэвидом Катлером и его командой постигал секреты многозадачности, реального времени, вмете с ними же, а позже со Страуструппом прошел все ступеньки от структурного к модульному, а затем и к объектному программированию.
И вдруг - обвал: земля разверзлась, и в нее канул DEC вместе со своими PDP11
и VAX11, RSX11 и VMS. Началась эра компьютеров "для домохозяек". И мне пришлось пересесть с VAX11 и VMS на PC 286 под MS DOS. Как я тогда матерился! Я обзывал 286-й программируемым калькулятором, MS DOS - дипломной работой выпускников школы для дебилов, а HELP по MS DOS - руководством, как его обойти! Но ко всему, в конце концов, привыкаешь...
Это был очередной "конец света", возвращение к каменным топорам и охоте на динозавров...
Самыми модными тогда были высказывания: "Зачем мне многозадачность, когда я и
с одной задачей толком не справляюсь..." и "Архитектура DEC - самая удачная экономическая диверсия
США в СССР!" :)
Мне, для того, чтобы работать в привычной среде и выполнять задачи реального времени, пришлось написать свое ядро, реализующее вытесняющую приоритетную многопоточность.
Я его запускал, как TSR программу, а запросы к DOS разделял через mutex. Но, к сожалению, надо что-то есть самому и кормить детей, так что развить это ядро в серьезную ОС мне так и не удалось...
Но все возвращается на круги своя. "Домохозяйки", наконец, взвыли: "Мы болше не можем работать с этим убожеством! Дайте нам что-нибудь посерьезней!" И в угоду потребителю, наконец, появились I386, I486, наконец, PENTIUM. Набор команд, наконец, стал сравним со старой доброй VAX11, а вся команда, написавшая опередившие время ОС, во главе с Дэвидом Катлером, была приглашена в Микрософт, чтобы спасти Б. Гейтса от позора его прошлых творений. Кстати, по моему мнению, им это удалось! Боюсь навлечь на себя гнев поклонников Linux, но на сегодняшний день я не знаю более мощного и стабильного ядра. За всю практику работы с NT у меня было всего 3 случая "синего экрана" (если не считать отладки своих драйверов), и все 3 случая связаны с неоттестированными драйверами "третьих" производителей. А все нападки на NT - это попытки сорвать злость на убожество Windows 95-98, и на монополизм Микрософта :)

Ну, вот, "выпустив пар", возращаюсь к тому, каким принципам нужно следовать при создании ОС (для чего она нужна, я , надеюсь, уже ответил).

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

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

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



To be continue...
Alexander
Создай свой УжОС
Библиотека разработчика ОС

http://subscribe.ru/
E-mail: ask@subscribe.ru 		Отписаться
Убрать рекламу

В избранное