Кто чего дельного (кроме исходняков каких-нить :] )по сабжу может посоветовать почитать или прямо здесь рассказать? А то ведь когда-нибудь я допишу свою собственную ос ;) до такого состояния, что придётся плотно задумываться на сабжевую тему. Сам в сети кроме общих слов ничего не нашёл :(

Кстати, не так давно, когда я ещё свято верил, что ide контроллер на моей "чёртовой зидовской мамке" (с) таки сумеет заработать в режиме udma33 (как ему положено по спецификации), я пытался писать драйвер для него под BeOS, ибо имеющийся драйвер не давал системе грузиться, если я включал поддержку udma. Как и что написать, чтобы данные, собственно, передавались - я в курсе. Однако, я так и не смог глубоко осознать, каким образом ОС даёт драйверу понять, что файловая система решила прочитать вооон тот сектор. Очень плохо.


Кстати, контроллер мой так и не заработал. Чего я только не делал (перепрошивал биос, патчил фирмваре винта, принудительно выставляя в нём, умеющем udma5, режим udma2, +...) - результата зеро. Включаю в биосе PCI IDE bus master - комп перестаёт грузиться. Биос не может найти загрузочную запись ни на винте, ни на сидюке.

Если вдруг кто может помочь - дайте знать, создам отдельный топик

coder
погляди Windows DDK...

Как ни приколько это звучит, но Windows NT - это в основе своей тоже микроядерная OS. Подробности смотри у Соломона с Руссиновичем, там был довольно интересная сноска на эту тему.

А принципы взаимодействия драйверов в NT хорошо известны. В настоящее время рулит модель WDM, основу которой составляет стек драйверов. Т.е. имеются драйвера шины (предположим USB) они отвечают за перечисление устройств, подключенных к данной шине, и за передачу данных по этой шине к устрйству.

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

P.S. Это конечно очень упрощенная картина. Подробности действительно в DDK.

MACH os
PHOENIX os
and so on and so on.

coder
А в чем проблема?
В классическом понимании микроядерная = клиент-сервер + многопоточное ядро.
С драйверами точно такие же принципы взаимодействия как и с "обычными" процессами.
Надо только подумать о контроле доступа, чтобы не "взаимодействовал" кто попало.

Sten
Как ни приколько это звучит, но Windows NT - это в основе своей тоже микроядерная OS. Подробности смотри у Соломона с Руссиновичем, там был довольно интересная сноска на эту тему.

Процитируй, пожалуйста, "интересный сноска", а то не могу найти.

А я тем временем процитирую Таненбаум "Современные ОС" стр 857

| Над уровнем аппаратных абстракций располагается уровень, содержащий то, что
| корпорация Microsoft называет ядром, а также драйверы устройств. В некоторых
| старых документах ядро называлось "микроядром", которым оно никогда не было,
| так как менеджер памяти, файловая система и другие основные компоненты
| системы постоянно находились в пространстве ядра и с самого начала работали
| в режиме ядра. Ядро определенно не является микроядром и сейчас, так как,
| начиная с NT 4.0, практически вся операционная система была помещена
| в пространство ядра.

[ captain cobalt: Процитируй, пожалуйста, "интересный сноска", а то не могу найти. ]

В русском издании стр. 25. В е-буке ищи "Is Windows 2000 a Microkernel-Based System?" во второй главе. Только там написано, что Windows 2000 как раз не основана на микроядре.

"Although some claim it as such, Windows 2000 isn't a microkernel-based operating system in the classic definition of microkernels, where the principal operating system components (such as the memory manager, process manager, and I/O manager) run as separate processes in their own private address spaces, layered on a primitive set of services the microkernel provides."