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

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

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

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

ну пусть называются нити, а не процессы.

А вообще, думается, что с помощью страничной адресации вполне можно осуществить передачу от одного процесса в ring0 другому.

А еще, когда тебе нужно что-то передать от одного процесса в ring3, другому, происходит переключение контекстов.

ну пусть называются нити, а не процессы.

ну, нити в ядре и так есть :).

с помощью страничной адресации вполне можно осуществить передачу от одного процесса в ring0 другому.

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

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

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

Поздравляю, ты только что изобрёл Singularity.

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

Являлась. IPC L4 (микроядро 2 поколения) быстрее обычного UNIX сискола

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

Именно так были устроены системы на Mach 2.5 и это НЕ микроядро.

Врядли, так как часто ли эта куча ядер будет нагружена разными задачами?
Иначе адресное пространство одно, и активного переключения контекстов итак не будет.

ЕМНИП в ней вообще основной фишкой являлась гарантия, что потоки для ядра и друг друга безопасны и покилять никого не могут. Можно ли это сделать на голом железе?

быстрее обычного UNIX сискола

пруф или не было?

По идее, переключения контекстов можно свести к минимуму, используя многоядерный процессор (10 и более ядер)

Переключения между ring0 и ring3 все равно останутся. А с микроядром их намного меньше не станет.

http://homes.cs.washington.edu/~bershad/590s/papers/towards-ukernels.pdf

страница 6:

Across-address-space IPC on a 486-DX50 takes 5 μs for an 8-byte argument and 18 μs for 512 bytes. The corresponding Mach numbers are 115 μs (8 bytes) and 172 μs (512 bytes). With 2 x 5 μs, the basic L4-RPC is twice as fast as a conventional Unix system call.

задержка при передаче данных от одного процесса другому

Вы серьезно?

D-BUS видели? а кучу демонов а-ля colord? А кучу слоев абстракции? ейчас такую «задержку» можно вообще в расчет не брать.

Главная проблема - любая нить может грохнуть ядро

это почему, помимо возможности засрать память?

это почему, помимо возможности засрать память?

именно поэтому. они же в одном адресном пространстве. Собстно, нить от процесса этим и отличается, по большому счёту.

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

Это вовсе не основная проблема микроядер, и ядер вообще. Основная проблема ядер это сложность их отладки и понимания процессов, которые там происходят. А микроядро делает отладку стократ сложнее. По условиям микроядер, вы должны обмениваться сообщениями с нужными «демонами» на каждый чих. Эти демоны строго изолированны друг от друга, имеют свои очереди сообщений и т.п. Даже оставляя вопросы производительности в стороне, когда у вас набирается сотня таких вот «сервисов», то понять, где затерялся байт уже будет сто крат сложнее.

Если же вы хотите делать всё «интегрировано», то у вас будет монолитное ядро, то есть Linux.

Даже оставляя вопросы производительности в стороне, когда у вас набирается сотня таких вот «сервисов», то понять, где затерялся байт уже будет сто крат сложнее.

Зато можно отлаживать отдельный сервис, а не все ядро целиком.

Можно же сделать один большой демон-OS-personality поверх микроядра и отладка будет классической

Можно же сделать один большой демон-OS-personality поверх микроядра и отладка будет классической

Это на 99% изменит поведение всего ядра (если мне не говорим о каком-нибудь L4/Linux, что ни капли не интересно), и отладка уже будет бесполезна. Ведь подавляющее большинство багов это именно баги взаимодействия разных компонентов.

Зато можно отлаживать отдельный сервис, а не все ядро целиком.

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

ring3

ring0

в природе существуют не только x86

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

AptGet

Вот, кстати, кто мне не верит, два Бога объясняют на пальцах (буквально):

http://www.youtube.com/watch?v=k84FMc1GF8M#t=24m35s

:-)

Да и вообще с ростом mips+flops скоро можно будет писать ядро на питоне.

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

я как-то задавал такой вопрос, мне кто-то сказал что так это и работает - без копирования

ЗЫ просто любопытно

это называется shared memory :)

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

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

В общем, как мы видем, всё время вырисовывается гибридная система :)

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

Ну эрлангеры же как-то отлаживают свои программы.

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

Да. Переключение контекстов не об этом. Если есть разные адресные пространства, значит надо менять таблицы MMU/cбрасывать кеши.

Это на 99% изменит поведение всего ядра (если мне не говорим о каком-нибудь L4/Linux, что ни капли не интересно), и отладка уже будет бесполезна. Ведь подавляющее большинство багов это именно баги взаимодействия разных компонентов.

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

L4/Linux, что ни капли не интересно

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

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

если не путаю, проблема называется inversion of control. Такие системы действительно отладить непросто если различные компоненты хранят своё состояние и их поведение меняется во времени. Другое дело что как ещё можно раздробить большу программу на более мелкие компоненты? Не писать же одним куском всё.

то понять, где затерялся байт уже будет сто крат сложнее.

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

Если сервис работает отдельным процессом, то куда проще его отладить на зараннее подготовленных тестах.

Поймите уже, что ошибка это не только «сервис упал», но и «у сервиса неправильное состояние/race/итд». Это состояние неправильное вовсе не очевидно. А сервисов этих овер дофига, и каждый нужно отдалить вместе друг с другом (а не по одиночке).

В монолитном ядре в одном драйвере бывает 3-4 потока исполнения (скажем user, пару irq и tasklet) — так там уже бывает мозг сломаешь, прежде чем поймешь где они косячат.

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

у сервиса неправильное состояние

по timeout возвращаемся в исходное состояние.

race

это от криворукости.

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

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

Читать 40 раз Ave Maria^W^WNot all the World is i386.

PS: я о том, что не везде есть эти кольца.

PS: я о том, что не везде есть эти кольца.

разделение на привелегированный/непривилегированный есть почти везде

по timeout возвращаемся в исходное состояние.

Причем тут timeout? С сервисом всё вроде ОК, он работает, отвечает, но сама логика взаимодействия неправильная. В сложной последовательности запросов A->B->C->D->E->F только на шаге E->F вы понимаете, что что-то не так. А сама проблема была в том, что шаг B выдал не те данные, так как другой сервис ожидал данных от шага E, и не послал нам нужного сообщения. Помножьте это на сотню сервисов и enjoy your debugging.

это от криворукости.

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

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

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

Если сервис работает отдельным процессом, то куда проще его отладить на зараннее подготовленных тестах.

Можешь представить себе ситуацию, когда все сервисы по отдельности работают идеально (то есть в соответствии с некоторыми спецификациями и соглашениями), но система в целом работать нормально не способна?

ударение на почти нигде так, как на i386 ;)

• i386, VAX — 4 уровня
• PowerPC, MIPS — 2 уровня (?)
• Sparc — 2/4 (?)
• AVR — 0
• ARM — 6, после v4 8 уровней (?)

UPD: http://semipublic.comp-arch.net/wiki/The_Proliferation_of_Privilege_Levels_si...

Похожим образом ядро в Mac OS X / iOS устроено, там вроде бы mach, вроде бы микро ядро, но весь драйверный, сетевой, VFS, итп код - в ring0, в том же контексте, что и микро ядро.

Ну приведи пример. Чтобы система именно грохалась.

AVR — 0

Нашел с чем i386 сравнить. А в остальных архитектурах есть привилегированный и не привилегированный уровни.

Один единственный протокол для связи всех процессов (9P) должен решить проблему?

man MS Singularity

Дедлок в котором участвует более 3х подсистем ;)

В принципе для дедлока достаточно и 2х, но с таким условием отлаживать будет очень вдохновляюще!

ЧТо значит грохнется? Если у тебя только дисковая и сетевая подсистема отвалятся, а остальное работать будет, система как - грохнулась или нет?