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

Narkomanius

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

Может приведёте определения?



При чём тут в NT 5.x - микроядро?!

Да там его отродясь не было.



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

Опять таки - не причём.



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



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

 

2 Edmon, не знаю...

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

Как тебе перевод?

2 Narkomanius, да ничего против микроядер я не имею!=))

хорошие штуки в своей области!=) Но еслибы они были идеальны смысл было тогда придумывать экзоядра?=)

 

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



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



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



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



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

 

кхм... похоже немного разные вещи действительно понимает под ядром...=)

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

 

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

/dev/io - allows process to obtain IOPL privilege.

 

+вот только qnx не надо копировать, даже в деталях. клиент-сервер - если щас начать под это затачивать, потом не переделать. ограничтесь простыми вещами - pipe, очередь сообщений(размером не более 256 байт каждое например) и семафор. сделайте шедулер, процессы, адресные пространства как отдельный объект, поддержку секций - чтоб у секции был владелец который знает где хранится содержимое и просвопывает его при страницном промахе. всем этим пусть рулит отдельный поток в ядре. он создает, удаляет и выдает процессам в пользование. само пользование оставить процессам. то есть запись чтение = это сами, а смена атрибутов, создание и удаление, поиск и открытие/закрытие - один процесс в ядре(чтоб всегда был доступен).





собсна шедулер то готов, но он работает быстро и адекватно пока пробуждено ограниченное колво потоков. если их больше то в угоду скорости качество планирования падает и стремится к FIFO. то есть там и есть фифо, но из него выбираются потоки не по очереди, а просматриваются самые старые N штук и из них выбирается самый лучший. плюс планировщик может удерживать загрузку проца в процентах не выше a% и не ниже b%. и там еще приоритеты рулятся множителем, определяющим вес времени процесса - 1 миллисекунда -> в k условных миллисекунд.

единственное что - все написано на C++ и не откомменчено вообще. могу ищо new() и delete() дать. но его надо дописать.

весь код сырой.

надо кому нить?

 

сорри за флут. как всегда не могу написатьь сразу все что хотел.

чем плохо клиент-сервер? а тем что на очередях сообщений можно организовать цепочки типа streams по которым будет пробрасываться информация. раздачу IOPL можно сделать спокойно, но вот подумайте над таким моментом - кто из вас сидит в одной программе? у мя щас MSVC6 Opera и гимп работают. а теперь задача: я в гимпе сохраняю картинку, быстро переключаюсь в вижуал и тама открываю какой нить другой файл. диск фрагментирован на 90 процентов и потому картинка на 60 метров сохраняется дольше чем я открою файл. как сделать чтоб программы в случае экзоядра поделили винт? как сделать неконфликтующим вывод звука? клаватуру? мышь наконец?.



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

 

Товарищи, про экзо будет скоро перевод второй и третьей части и они как раз на все эти вопосы отвечают... Сам пока внятно ответить не могу...

 

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

 

только вот со свопом проблема будет на smp-системах.

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

 

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

 

задача - есть секция, отображаемая на диск в процессе Бэ

процесс Цэ захватил в монопольное пользование винт. процов 2, ну пусть даже 1 но они же могут переключаться. например Бэ высокоприоритетный.

в Бэ происходит #PF. так что - ждать пока Цэ отпустит диск, извращаться посылаю Цэ что нить тама(а откуда он знает об адресном пространстве Бэ ?) что вызовет такие накладные расходы на написание сложного кода, что будет легче юникс написать, или поставить семафор, пусть все лочат его при начале обращения и анлочат в конце. тогда все будет пучком.

 

Edmond

Учится я еще не закончил, сейчас прохожу преддипломную практику в СПбГЭТУ(ЛЭТИ).



Narkomanius

Нельзя процессам винт в монопольное пользование отдавать! Как абсолютно верно было замечено, для каждого ресурса должен быть объект который будет контролировать к нему доступ. А картина эта выглядит так:

У каждого процесса-сервера есть очередь(а может даже несколько) запросов. В очереди у каждого сообщения есть атрибут - идентификатор процесса отправителя. По этому атрибуту процесс сервер определяет в каком порядке отрабатывать запросы.

В процессе Б происходит #PF. Обработчик PF отправляет сообщение диспетчеру подкачки, и вызывает планировщик, чтобы он переключился на другой поток. Если в данном процессе есть еще потоки готовые к выполнению, то переключение произойдет на один из них, иначе произойбет переключение адресного пространства и начнется выполнение потоков другого процесса. Диспетчер подкачки отправляет сообщение драйверу диска(тоже процесс). Если диск выполяет операцию по запросу процесса Ц, то когда эта операция будет завершена драйвер диска проверит очередь и извлечет от туда запрос от диспетчера подкачки(он то уж точно должен быть одним из самых приоритетных), а после его обработки отправит сообщение диспетчеру подкачки. Диспетчер подкачки, получив сообщение о загрузке требуемых данных, исправит таблицы трансляции и отправит сообщение планировщику, чтобы тот добавил поток процесса Б в очередь потоков, готовых к выполнению.

 

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

а теперь объсню почему экзоядро сосет в плане защиты.



просто по одной причине - дрова в Ring3, и стек даже у системной библиотеки можно переписать если есть несколько потоков. то же самое о её данных. конечно можно выдать каждому потоку свое адресное пространство, это будет работать очень эффективно если мапать секции по адресам кратным 4М, то есть хранить одну 4к страницу под каталог страниц. это иначе будет тормозить и что самое главное - жрать рам!

 

Narkomanius

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

 

И что собственно вы желаете этим высказать?

 

Читал эту фразу раз 10.

НИХРЕНА НЕ ПОНЯЛ )

У меня создаёться впечатление - что Вы бредите, или подключили поток своего сознания напрямую к форуму.



Это форум - а не дневник Васи пупкина.

Фильтровать надо!



Да ВЕДЬ распределение ресурсов - это всегда задача, которая идиально решается ТОЛЬКО клиент-серверной архитектурой.



Стоит ли об этом говорить?



Экзоядро, микроядро, ядро. Я так и не УСЛЫШАЛ тут ОПРЕДЕЛЕНИЕ ЯДРА!!!



Да ЗАБУДЬТЕ ВЫ ПРО ЯДРА!!!!!!



Вот послушайте Black_mirror

- чёткая архитектура ОС.



Тезисы:



1. ОС - это совокупность объектов.

2. Объекты могут иметь интерфейсы.

3. Объекты могут быть сервером или клиентом по отношению к друг-дугу

4. Объекты используют потоки данных для обмена данными между собой.

5. Интерфейсы могут наследоваться - то есть обладать иерархией.

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



Всё - нет никакого ядра. Нет и не было. Есть просто объекты, серверы и клиенты.



Планировщик - объект

Потоки данных - специальный объект

Драйверы устройств - это такие объекты.

Приложения - тоже объекты.

 

Edmond ты конечно прав, на счет структуры, ос ...

я могу добавить лишь то что ядро это менаджер ресурсов и администратор прав ну и наверное еще менаджер над сервисами которые могут быть. Ну это очень утрировано.



У меня к тебе вопрос следующий - где можно узнать програмные модели процесоров не только х86 но и PowerG

и тд.

 

„чем плохо клиент-сервер? а тем что на очередях сообщений можно организовать цепочки типа streams по которым будет пробрасываться информация.“



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



„выработаем какие нибудь механизмы синхронизации.“

см. сюда, писал же уже

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

если это не очень понятно, то объясню как оно должно происходить на примере винта:

винт подключен к ide0

допустим что для ide0 есть семафор s_ide0

что делает процесс

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

Код (Text):

1.  
2. лочить_память_c_которой_щас_будем_работать();
3. lock(s_ide0);
4. послать команды;
5. if(sleep(some_timeout)==some_timeout){
6. //управление вернулось по срабатыванию таймера - таймаут кончился.
7. //значит произошла ашипка или глюк
8.      ругаться_матом();
9. }else{
10.      //предполагается что процесс не будет обматерен тут ничем кроме IRQ
11.      сделать_что_нить_полезное()    
12. };
13. unlock(s_ide0);
14.  

что делает ядро при получении IRQ:

смотрит какому устройству назначено IRQ, и кем оно залочено.

посылает залочившему процессу сигнал SIGIRQ.

если таковых нету, игнорит IRQ.

 

1. ОС - это совокупность объектов.

2. Объекты могут иметь интерфейсы.

3. Объекты могут быть сервером или клиентом по отношению к друг-дугу

4. Объекты используют потоки данных для обмена данными между собой.

5. Интерфейсы могут наследоваться - то есть обладать иерархией.

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

Всё - нет никакого ядра. Нет и не было. Есть просто объекты, серверы и клиенты.



щас я буду издеваться

1. а кто отвечает за связи между объектами? или они сами по себе?

2,3 - пересказ очивидного

4 - не определены потоки данных

5,6 - классы тоже наследуются. пункт имхо просто взят с потолка изза того что афтар придумывая его поглядел на п.1

особенно порадовал вывод - ядро не упомянуто, зато есть п.1 в котором хромают взаимосвязи между объектами, свободный пересказ концепций ООП + ищо одно недоопределение в п.4