Проектирование ОС

я типа могу присоветовать что нить. только сперва вопрос: что требуется от оси?

про дрова - может стоит их запускать как отдельные потоки в ядре, и прерывания им посылать как сигналы. ввод вывод можно вести через например очередь сообщений типа /dev/a0

 

про конкрутную ось пока ничего сказать не могу.

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

советуй! я всегда готов послушать...=)

_____________________

а почему бы вообще не избавиться от дров? со скриптофилософией это вполне реально. код остаётся одинаковым, просто требуется перекомпилировать...

(я конечно не говорю о таких девайсах, которые часто меняются(хотя мне такие тяжело предстваить)) ведь винт/проц/видяха не так уж и часто меняются. А то уже надоело общатся с дровами...

 

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

 

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



как в экзоядре закрыть доступ к всем устройствам вообще? если прога например вирусная.

ну например так - для каждого процесса создается список точек входа в библиотеки. ядро при попытке вызвать точку входа получает #PF - т.к. страница с точками входа помечена как отсутсвующая. после чего выставляет IOPL=3.



библиотека потом может его установить в 0 и вернуть управление. но надо еще решить вопрос с разметкой памяти и что самое главное - с планировщиком. его в принципе можно запустить как отдельный процесс, и в оси сделать 2 сискалла - вызвать планировщик и вернуть IOPL как было. но надо продумать IPC - а то в задницу такую ось, где приложения друг о друге не знают.

 

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

На данный момент делается вроде так... перед запуском приложения его код сканируется на предмет обращения к ресурсам со всеми вытекающими последствиями.=))(никто не говорит, что и нам так же надо делать). А вообще в экзоядре ОС - это обычное приложение и есно их может быть несколько=))) Может быть даже так, что одна программа может вызывать функции Линукс, WinAPI и ещё иметь прямой досиуп к аппаратуре.=)))

Если интересно, то могу выложить статейку по экзоядру(маленькая - 12 страниц, но на англицком)

 

Здарова Хлопцы! Это, ну я конечно уже немного пообщался с eXodом, но правда опсуждений было еще аж неодного,

но вот услышал речи Narkomaniusа и сразу вопрос:

Мужики а зачем для програм вам прямой доступ к аппаратуре?

Зачем??? Может всетаки подумать о кроссплатформенности? Ведь эта затея куда перспективнее. К томуже когда все пацаны софтостроения переходят но безопасный софт и виртуальные машины, то я считаю что это нужно учесть. Я конечно люблю Асм и дрюкать девайсы из портов тоже, но ведь это все не должно выходить за рамки драйверов! Интересно, как вы думаете: через 5-10 лет пацаны все так же будут чтото строчить в Асме? Да будут, но не то что строчат сейчас. Да уникальные девайсы будут всегда, и не уникальные тоже, и поэтому дрова писать будут тоже всегда,

и естественно что один из лучших языков будет Асм. Но Господа, система должна быть максимум стабильной!!! Скорость тоже не последний параметр. Поэтому я считаю что

Уровень абстракции над железом не только нужен, да он ваще просто НЕОБХОДИМ! А на счет того что дрова запускать в режиме ядра - а зачеи? Что это дает? Может просветите невежду, может ктото и не помнит или не задумываеться но кривой драйвер может запороть Ось в две секунды и со сто процентной эффективностью. Поэтому есть предложение их опускать тоже в разряд обычных приложений, естественно ядро не должно их выкачивать в своп а то прикольно будет - драйвер винта для свопа в свопе ))). Ну да ладно

есть еще одно:

С че м я согласен на 100 пудов так это с тем что как предложил Narkomanius - <для каждого процесса создается список точек входа в библиотеки> Да это правильно и жизненно необходимо чтобы обеспечить контроль над любым процессом. Идея в том что для каждого приложения подбиваеться список того что ему нужно по замыслу (причем это происходит на этапе дизайнтайма) а если полномочия превышены - милости просим в Аут .

А как ты Narkomanius смотришь на это?

 

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

А кроссплатформеность решается за счёт использования нового компилятора исповедующего скриптофилософию.=) Да собственно все приложения в экзо и исполняются на ринг3(не помню здесь кто-то вроде говорил... так рингов на самом деле 0,1,2,3 - только используется в основном нулевой и третьий). Воть.

 

eXod

Ещё раз советую обратить внимание на Архитектуру Винды (Драйверы).



Скриптинг устройств - это действительно продвинутая дрянь.

Но. Сами драйвера то всё-равно нужны. А как они будут получены - это никого не интересует.



eXod

Одна из самых мощных моделей абстрагирования (о которой не жалко рассказать )) - это сервер-ядерная модель.



Она в принципе юзается в Винде и частично в Uinux.



Но так, чтобы вся Ось была построена по такой архитектуре - такого всё же не было (наверно потому, что мозг человека инерционен).



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



(Вообще прикол выход... Если создать такую ОСь - то получается что при небольшом переписываении кода - Ось может стоять не на 1 машине а на 2.... и так далее)





Основной плюс серво-ядерной модели - это высокая гибкость.



Опережая ваш вопрос - "а расскажите подробнее".



TCP/IP - это некое подобие того, что можно сделать.

Дык - а перевести Статья интересная?

Не скажи

Как бы в будущем не оказалось- что всё железо будет стандартизировано по интерфейсам.

НО ЕГО ЛУЧШЕ ДЕЛАТЬ КОМПИЛИРУЕМЫМ, а не ПРОГРАМНЫМ.



И в ЭТОМ ЕСТЬ ЛУЧШАЯ ИДЕЯ ВСЕХ ВРЕМЁН И НАРОДОВ!



Только её никто не понимает

На самом деле не совсем бы и так.



Это в том случае - если ядро будет отдельным тредом.



А почему бы ядру не выделять специальное адресное пространство - которое будет ему доступно при ОБРАЩЕНИИ этого процесса к ядру (как это сделать - это уже другой вопрос), и которое будет находится в СОСТАВЕ самого процесса (но так, чтобы процесс не имел к нему доступ)



Тогда сами "точки входа" будут ПРИСВАРЕНЫ к программе.



При разрушении процесса - выделенные ресурсы легко уничтожить, потому что информация о них - находится в одном месте.



Остаётся вопрос - как сделать так.

Есть много хороших путей.



(Смотрите ту же Винду [FS])

 

Несколько слов о планировщеке.



Зачем с него делать процесс?



Планировщик - находится ЛОГИЧЕСКИ ниже УРОВНЯ понятий "процесс".



То есть то, о чём тут говорится - уже бред по определению.



Тут самое важное - чтобы планировщик работал как можно МЕНЬШЕ (по времени).



Тут можно придумать было бы настраивамые кванты.

То есть чтобы в зависимости от нужды - планировщик либо увеличивал длинну ОДНОГО кванта (на таймере), либо уменьшал.



А алгоритмы распределения времени между процессами - это уже другая сказка



Дело в том. что к планировщику ОБЯЗАН быть привязан ещё один механизм - механизм запроса.



То есть когда например просыпается процесс с более высоким приоритетом - он получает свой квант времени сразу.



А ВЕДЬ НИТИ пробуждаются ТОЛЬКО по СОБЫТИЯМ!



Вывод - МЕХАНИЗМ событий ПРОХОДИТ ЧЕРЕЗ ПЛАНИРОВЩИК!

Вот например...



Пусть каждая нить (именно нить а не процесс)



имеет приоритет от 0 до 31.



Пусть таблица расчёта приоритеттов - выглядит в виде

простого линейного списка очереди.



НО!!!! Мы условимся, что приоритет нити НА САМОМ - зависит

ОТ местоположения дескриптора в списке.



ТОГДА = ПРИОРИТЕТ вообще не нужен



Пусть в этом списке, который состоит из Указателей на структуру нити и приоритета.



Присутстуют специальные макеры...



Я буду маркировать обычные указатели как ->, а не маркеры *. Вот как выглядит этот список.

каждый элемент





Обратите внимание на избыток информации.

Одна и та же информация хранится несколькими способами.

цель такого пересбытка - повышение скорости работы.





[маркер начала*][чило элементов в уровне][счётчик тиков][->][->][->][маркер конца уровня 1*][чило элементов в уровне][счётчик тиков]

[->][->][->][маркер конца уровня*][чило элементов в уровне][счётчик тиков]

[->][->][->][маркер конца уровня*]



Планировщик - разделяет кванты времени только между задачами ОДНОГО уровня.



Достаётся и другим - однако - это другой вопрос.

(Мы его пропускам)



Для планировщика распеределение времени между маореками одгого уровня - дело простое. Крути себе шарманку в цикле, между элементами уровня.



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

ИЛИ ВАРИАНТ 2.

Если в пределах одного уровня нити имеют свой приоритет.

(назовём его - локальным) пусть он равен от 1 до 7

то - планировщик даёт ните столько тиков (в пределах уровня), сколько имеется в локальном приоритете.

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



ПРИ ЭТОМ - он постоянно понижает счётчик тиков.

Для чего он?

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

Счётчик тиков - это время голодания для процессов с низким уровнем.



Когда счётчик тиков доходит до нуля - планировшик спускается на уровень вниз, и смотрит - кто там хочет выполнится...

ПРИ ЭТОМ он уменьшает счётчик тиков того уровня!!!

ЕСЛИ счётчик того уровня равен 0

планировщик спускается ещё ниже..

И так далее - пока уровни не будут исчерпаны.

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



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

P.S.

Когда нить меняет свой приоритет - планировщик обязан переместить её внутри списка...





Но на самом деле, он может пометить её (ведь каждый элемент содержит ещё и проритет) - а сам совершить перенос намного позднее - когда будет удобно.



Таким образом задачи планировщика сводятся к минимуму действий.



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

А вот когда просыпается процесс из более высокого приоритета (а просыпается он всегда ТОЛЬКО по какому НИБУДЬ СОБЫТИЮ)...

Вот тогда планировщик отдаёт время ему.



И всё повторяется



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

Это то, о чём я говорю В реалльности - код МОЖЕТ БЫТЬ монолитом - а в программе - пусть будет ЛЕСА этих абстракций.



Кроме того - Я ПРОСТО НАСТОЯТЕЛЬНО РЕКОМЕНДУЮ реализовать серверную модель объектов и ПЛЮНУТЬ на ЭТОТ ООП - он уже давно морально устарел.

 

2 Edmond, эх как я согласен с тобой по поводу ООП!=)

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

со статейко про экзо... постараюсь перевести в ближайший день/два и выложу. А по поводу компилятора я немного написал в топике о валькирии.=))

 

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



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



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



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



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



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



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



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



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



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

 

Что значит где? Как и все - из мозгов.

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



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

Мда...



Кстати вот.

Вытащил со шкафа книгу Вахалии.

UNIX изнутри.



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



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



1. Классы нитей

2. Группы нитей (это и есть процессы)

3. Пространства нитей (...)



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



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



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



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



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

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

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

 

Black_mirror



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



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



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

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



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



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



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



-------------------------

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

-------------------------



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



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



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



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



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



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



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

Код (Text):

1.  
2. #0Server::SServer::{
3.  
4. ..... тело сервера......
5.  
6. }::SServer::0Server#
7.  

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



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

2. Удалять участок



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

Код (Text):

1.  
2. #0Server::SServer::{
3.  
4.       // объявление порта "new"
5.       #port::new::{
6.           // описание реакции на действие
7.           // по отношению к порту new
8.           // которое выделяет ресурс          
9.       }::new::port#
10.  
11.       // объявление порта "delete"
12.       #port::delete::{
13.           // описание реакции на действие
14.           // по отношению к порту delete
15.           // которое удаляет ресурс          
16.       }::delete::port#
17.  
18.  
19. }::SServer::0Server#
20.  

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



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



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



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



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



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

 

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



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



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

 

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

1397142622__my_exo.zip

 

тык. короче я вернулся и все такое.

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

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

 

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

офф:

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

 

млин да абстракция от аппаратуры всегда нужна!!!!

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

 

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

а ещё можно и напрямую к аппаратуре обращатся(нет в микро, а многим бы это понравилось)=))

И изгалятся как хочешь - работать всё равно будет!(надеюсь)=)

 

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