микроядро в kernel-space

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

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

Но что, если поместить все эти процессы в ring0? Это несколько снизит надежность, но избавит от переключений.

Так то оно так, но система такая перестанет быть микроядерной, и начнет быть старым добрым монолитом.

Так то оно так, но система такая перестанет быть микроядерной, и начнет быть старым добрым монолитом.

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

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

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

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

Напиши письмо деду Андрею Ёлкену. То-то старик порадуется!

П.С. Линуса в СС не забудь добавить.

переодический дедлок который будет блочить все на Н секунд.

во-первых не все, а только то, что затронуто им.

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

Да там не так много сервисов, так что считай что затронуто все ;) Кого убрать? Драйвер ХДД убрать? И потом что? )

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

Разница только в том что ты предлагаешь эти нити запускать в отдельных процессах.

Но все таки идея о том что можно что-то выгрузить из ядра (если речь идет о чем то более важном чем beep.ko) кажется мне сомнительной.

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

Мне кажется архитектура _кода_ в данном случае играет большую роль.

Черт, я тебя не так понял. Да, убрать дедлок, это хорошая мысль ;)

можно что-то выгрузить из ядра

выгрузить и загрузить по-новой.

Если сначала выгрузить драйвер хдд, то могут быть некоторые сложности ;)

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

в L4 это называется Map/Grant/Revoke

Правда, если у нас есть shared memory между процессами то это вроде как не совсем microkernel, ведь всё должно передаваться только через диспетчер, а тут оптимизация передачи данных.

вполне себе микро. в L4 диспетчер независим от ядра, любой процесс может иметь свою реализацию диспетчера. а управление идёт на базе трёх операций: map, когда процесс может запросить в своё адресное пространство немного байтов, grant, когда один процесс отдаёт другому выделенные им байты (например, тот же диспетчер — запросившему память процессу), и revoke, когда получивший процесс говорит, что ему эти байты больше не нужны.

таким образом, всё пространство (сигма ноль) делится между процессами, которые через map/grant/revoke выясняют, кто из них главнее и кто кому память отдаёт.

Интересно было бы иметь разные os personality.

велкам инто экзоядра.

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

велкам инто миникс ос с рестартами

Какое же это микроядро?