Несколько мыслей по поводу ОС:

ОС - объект(система) владеющий всеми ресурсами вычислительной системы и предоставляющий их другим объектам для решения их задач.

Систему объектов решающих какую-либо задачу, так же можно рассматривать как объект.

Состояние объекта - информация, которая нужна объекту для принятия решений.

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

Так как в большинстве существующих систем отсутствуют "железные" методы изоляции объектов друг от друга и распределения времени внутри процесса, придется сделать двухуровневое управление ресурсами: "жесткое"(осуществляемое ОС) между процессами и гибкое(для которого программистом может быть создан свой диспетчер ресурсов) внутри процесса. Управление памятью в существующих системах так и сделано, а вот для управления временем нужно будет сделать функцию которая позволит устанавливать таймер в пределах кванта отведенному для данного процесса, и при истечении времени вызовет внутрипроцессный планировщик, чтобы он мог передать управление методу другого объекта.

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

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

От файловых систем нужно перейти к системам хранения объектов. У каждого объекта(программы) может быть каталог, в котором будут хранится объекты и ссылки на объекты к которым объект может получить доступ. К тому что не попадает в этот каталог доступа быть не должно. Для каждого пользователя создается представляющий его объект, который загружается в память и может взаимодействовать с другими объектами.

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

„Млин, сколько ценных мыслей... если не секрет, где берёшь информацию?“

Что значит где? Как и все - из мозгов.
Вообще-то это было написано и одновременно додумано (хотя не придумано) за 5 минут.

у меня обычно главная трагедия в том, что каждый раз я узнаю, что кто-то это уже придумал до меня :))
Мда... :)

Кстати вот.
Вытащил со шкафа книгу Вахалии.
UNIX изнутри.

Посмотрел, что он пишет про приоритеты.

И хочу добавить, что ко всему описанному можно добавить ещё

1. Классы нитей
2. Группы нитей (это и есть процессы)
3. Пространства нитей (...)

Кстати описанный алгоритм - очень неплох.

В отличие от динамического перерасчёта приоритета :)

Так что можете ставить мой (c) ^)))

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

Причём к нему может быть легко добавлены все три пункта, приведённые перед тем.

„там по моему написано про клиент-ядерную технологию=) “

Жалею, что не написал цикл статей Мифологии Программирования :) Нет бабок, чтобы самому себе за это заплатить... :)), впрочем как и цикл алгоритмов "Управление памятью"

„со статейко про экзо... постараюсь перевести в ближайший день/два и выложу.“

Очень хорошо!!!

Black_mirror

Снимаю шляпу - замечательно. Что ты оканчивал? :)

Ладненько. Раз такая пьянка пошла... пора встряхнуть мозги.

========================================================
Серверно-ядерная модель взамодействия

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

Сервером называется такая система, которая позваляет управлять некоторым множеством ресурсов, только посредством обращения к серверу.

Сервер - является видом ядра.

-------------------------
Давайте забудем про ООП...!!!
-------------------------

Здесь я постараюсь привести пример серверной модели на предельно простой задаче распределения ресурсов.

Пусть есть множество ресурсов вида площадь.

Элементов площади есть квадратный метр.

Покупатели используют понятие "участок" - для группирования ресурса площади.

Участок имеет некоторую площадь большую или равную одному метру квадратному.

Знанием о всём ресурсе площади обладает ТОЛЬКО один, и только один объект - SServer - который является ядром

На некотором языке программировния его можно было бы описать так:

#0Server::SServer::{

..... тело сервера......

}::SServer::0Server#

Сервер SServer умеет делать только

1. Выделять участок
2. Удалять участок

Например это можно описать так:

#0Server::SServer::{

      // объявление порта "new"
      #port::new::{
          // описание реакции на действие
          // по отношению к порту new
          // которое выделяет ресурс          
      }::new::port#

      // объявление порта "delete"
      #port::delete::{
          // описание реакции на действие
          // по отношению к порту delete
          // которое удаляет ресурс          
      }::delete::port#


}::SServer::0Server#

Ядро-Сервер обладает портами - к которым можно послать возбуждение - и получить ответ сервера.

Однако стоит заметить, что Сервер НЕ управляет Самим участком. Для этого как правило ОН создаёт объекты.

(Вот тут смотреть ООП - похоже)

Объекты сервера - всегда имеют свзязь с ним, и сервер всегда "знает" о ВСЕХ своих объектах!

Именно такое распределение информации в системе является наиболее оптимальным и удобным для программирования, так как программист ЯВНО описывает МЕТОДИКИ управления РЕСУРСАМИ.

========================================================

Я надеюсь это не противоречит закону ?

Еще советую книгу "Путь камикадзе"

http://anatolix.naumen.ru/itmanagementbooks.htm

Итак, я ту кое-что напереводил=) Получается довольно медленно(нижеследующий кусок перевёл часа за 4-ре) ибо плохо знаю английский. Эту же статью(вернее введение) переводил antifatum, но там довольно много неточностей в переводе. Я старался переводить близко к смыслу, а не к тексту. Пока представленно только полностью переведённо введение. Жду ваших отзывов и предложений по качеству перевода(так же хотелось бы узнать надо ли дальше переводить).

1397142622__my_exo.zip

тык. короче я вернулся и все такое.
во первых зря вы так микроядро пинаете. потому что винда2к - микроядерная, а игрухи летают. ХР - тоже самое. дело в том что процессы погут работать в ядре - типа в пространство ядра подгружается файлик и из него вызываются функции в ОТДЕЛЬНОМ потоке. и все общение идет через стандартные для оси механизмы IPC. сам такое и делаю. минимально в ядре должно быть это самое IPC, планировщик, делилка памяти и что-то что органитзует доступ к процессам и IPC. то есть я хочу создать семафор и юзать его совместно с другим процессом - я куда то отправляю извещение о том что вот у меня есть такой-то ресурс и я хочу чтоб все его видели под таким-то именем
а если хочу открыть его - посылаю запрос что мне нашли этот ресурс от открываю его. сидит отдельный процесс(в ядре обязательно-т.к. он должен работать без задержки.) он сам выделяет память ищет по именам и т.п. а процессам просто раздаёт указатели на ресурсы с определеныым доступом. и на этото процесс можно взвалить безопасность и т.п. а уж все фичи - по усмотрению. дрова ведь будут доступны(или нет - как права выставлены)

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

млин да абстракция от аппаратуры всегда нужна!!!!
хоть на уровне либлиотек. в статье может все и гладко, а на деле то - нет. самый простой пример - разметка памяти. как все просто было придумано у меня - а на деле выходит что нифига не удобно. тоже и про общие IPC - щас приходится каждый поток делать как отдельный процесс(имеется ввиду не адресное пространство а список открытых ресурсов потому что так можно избежать ссылок на другие структуры.(при совместном доступе они будут источником багов ипросто писать больше в три раза.)

дык в экзо абстракция есть! =)) только не жёстко заданая, выбирай какую хочешь или пиши свою! Да к тому же это всё ещё и одновременно работать будет!!!(в отличии от микро, где заданные абстракции поменять нельзя)=)))
а ещё можно и напрямую к аппаратуре обращатся(нет в микро, а многим бы это понравилось)=))
И изгалятся как хочешь - работать всё равно будет!(надеюсь)=)

вот ищо "нет в микро" - XWindows как по твоему работает? iopl умеют выдавать даже монолитные системы типа уникса. сделай микроядро с раздачей прерываний и возможностью получить iopl.

Narkomanius
Мне что-то кажеться что тут что-то не понятное подрузамевается под ядром и микроядром.
Может приведёте определения?

При чём тут в NT 5.x - микроядро?!
Да там его отродясь не было.

При чём тут модель STREAMS (пример: xWindows) к микроядру?
Опять таки - не причём.

Ядро операционной системы - ВСЕГДА (как минимум архитектурно) абстрагировано от аппаратуры (пускай и не всей).

Так что я не понимаю господа о чём вы тут вообще спорите...

2 Edmon, не знаю...
хотя насчёт того, что ядро абстрагировано от архитектуры - это ты наверно зря... может оно предоставляет абстрагированные от архитектуры абстракции?(сорри, за тафталогию). всё же, мне кажется, что ядро не должно быть абстрагировано, а иначе это будет таааааак медленно...=)
Как тебе перевод?
2 Narkomanius, да ничего против микроядер я не имею!=))
хорошие штуки в своей области!=) Но еслибы они были идеальны смысл было тогда придумывать экзоядра?=)

„хотя насчёт того, что ядро абстрагировано от архитектуры - это ты наверно зря...“

Это всё потому, что границы ядра ОС - тут плохо определены.

Мы что понимаем под ядром ОС?

Часть кода, которая управляет некими минимальными бызовыми структурами типа поток или процесс, или что-нибудь ещё, паспределением памяти?

Так в этом случае многие алгоритмы - абстрагированы даже от процессора.

Я что-то не так сказал?

кхм... похоже немного разные вещи действительно понимает под ядром...=)
если действительно брать управление базовыми структурами, то общий алгоритм действительно не зависит от аппаратной части, хотя детали реализации(не алгоритма),ИМХО, сильно зависят от аппаратуры.

При чём тут модель STREAMS (пример: xWindows) к микроядру? Опять таки - не причём.
/dev/io - allows process to obtain IOPL privilege.