> Ну можете. Но как вы определите, что функция одного драйвера в ядре
> затёрла память другого драйвера ядра? Вы же не анализируете расположение динамически
> выделенных таблиц.До некоторой степени можно по адресам разных сущностей, все-таки карта размещения оных - генерится. Именно заезд в чужой динамический массив - сложнее, скорее всего понадобится какой-то костылик в аллокаторе проверяющий это явным образом. С другой стороны, у медали есть обратная сторона: можно сделать из бага фичу. И все эти очень эффективные zero-copy, фокусы с тасовками страниц и прочая - они ведь по другому не прокатят. А там где гигазы в секунду летают, все это совсем не лишнее.
А вообще, там где нужна именно супер-надежность, динамическое выделение памяти надо вообще гнать взашей. Источник потенциальной ненадежности. Ибо если что-то может обломаться - оно обломается. Критичные системы которые напрямую рулят чем-то опасным обычно делают минимальными и с полностью статичным разделением памяти. Кстати по подобным соображениям в очень критичных системах есть еще и правило с запретом арифметики указателей как потенциально опасной. Да, си может быть и очень безопасным языком для очень критичных применений. И в таких системах упор не на поимку сбоя, а на его абсолютное недопущение. Ну, раз уж оно критично - значит критично.
А линукс все-таки скорее ОС общего назначения, а не средство руления ядерным реактором напрямую, где зафэйленная аллокация памяти может вызвать "большой бумс" самым непосредственным образом, т.к. стержни видите ли заклинило и реактор по этому поводу пошел вразнос. Если так получается - это просто грубая ошибка в дизайне уровней системы. Все-таки, если память выделяется динамически, вполне возможно что аллокатор заявит что выделять ее вот прям сей момент - неоткуда. А вот это уже как бы проблема - корректное функционирование при этом будет нарушено точно. Ведь если память выделяли - наверное не для красоты?
> Да, но хоть часть проблем уйдёт. Это уже неплохо.
Зато появится куча других проблем. В целом как видим, микроядра о которых бредят академики в основном только академикам и оказались нужны. В силу того что выжать из этого дизайна практически интересные параметры - примерно так же просто как получать из токамаков энергию в промышленном масштабе. Ну вот и процветают какие-то иные дизайны в массе своей. А микроядра обитают в каких-то специальных областях. Ну и пусть себе обитают.
> А зачем лишний раз копировать? Есть всякие варианты с shared memory.
В микроядрах все это сильно сложнее получается.
> Да. Наш дедушка пахал плугом. И мы будем делать то же самое.
Не, ну конечно можно пытаться прикрутить к плугу реактивный двигатель, с аргументацией что это намного технологичнее и современнее. Но зачем? Есть уверенность что оно такое будет хорошо работать и радовать пахаря и тех кто зависел от результата его труда?
> NT подгадило то, что память тогда была очень дорогая.
Изначальному дизайну, с видеодрайверами в режиме пользователя, подгадило прежде всего то что графическое окружение в нем безбожно тормозило. MS очень конкретно на это взъелся и засунул в ядро не только видеодрайвера, но и вообще заметные куски GDI (в выноске win32k.sys). Вот это уже даже оверкилл. Но графика втопила конкретно. И вскоре NT захватила мир.
Замечу что даже в том же пингвине в попытках получить от графической подсистемы приемлимую производительность пришли к в чем-то похожим вариантам - низкоуровневые выноски для совсем базовых операций - все-таки внесли в ядро. До такой жести как win32k.sys на несколько метров в режиме ядра конечно же не дошли. Все-таки XXI век на дворе, компьютеры стали быстрее, да и куча проблем с секурити показывает что так делать не следует. Но кое-какие общие идеи все-таки кочуют по разным дизайнам.
[skip]
> Какое отношение имеет граф. система
В принципе - никакого. Это лишь как пример было приведено.
> к общесистемной шине для редких событий?
Это вы придумали что оно для редких. А как по мне так допущение что "для редких" это большой продолб на этапе проектирования. Потому что на практике окажется что нифига не редких и систему начнет радостно клинить там и тут.
> Или вы собрались о каждом кадре фильма оповещать народ?
Каждый кадр - это еще ладно. А почему должно быть нельзя слать логи всем заинтересованным подписчикам? А если это сервер с 5K RPS - это не 25 кадров фильма. Это 5K сообщений в секунду. И это кстати весьма скромный PPS.
> "Your mouse have moved. Press any key to reboot."
Вот шина с допущением что сообщений будет мало - что-то такое, да.
>> По такой логике и TCP/IP должен отдельный демон делать.
> По хорошему - да. Это микроядерная концепция. Просто каждая строчка стека
> TCP/IP выходит по цене Шекспировского тома. На отладку всего и всея таких ресурсов нет.
Как бы мне не нужна система где на регулярной основе падают драйвера, сетевой стек и что там еще. По поводу чего мне не очевидно чего ради меня должно волновать что система может видите ли попытаться изящно заменить обделанные панталоны.
> Там однозадачные системы.
Не обязательно кстати. Могут быть и RTOS. Правда там список задач обычно хардкодед, как и распределение памяти.
> А раз другие задачи, то и другие решения. Это, как бы азбука. Даже неловко напоминать об этом.
Ну так я и пытаюсь вам намекнуть что от обычного ширпотребного автомобиля (Linux) никто не требует надежности и технологий как у космической ракеты (микроядра).
> Ну вот, предлагаю арбитраж - до 10-ти собщений в секунду. Сообщение до
> 140 символов. На вытаскивание флешки этого хватит.
Угу, а потом оно начнет обрастать костылями как старикан х86. В половине задач придется делать пакетизатор/энкапсулятор, который сможет через это дерьмище пропихнуть то что на самом деле было надо. С немеряными буферами, пересборкой фрагментов и прочая. Во блин счастье.
В общем, если вам зачем-то нужна такая шина - идите и делайте. А я со своей стороны обещаю не пользоваться таким уродцем ни при каких обстоятельствах. Т.к. это нечто из разряда "а давайте у нас будет полтора регистра на весь проц и только 16 битов на адрес?!" :)
> Использовать просто. РЕАЛИЗОВАТЬ сложно.
Если будет наоборот - никто просто не будет пользоваться геморной системой. И вообще, сравнив как работают ядерщики и другие граждане, я поймал себя на мысли что намного больше доверяю тем парням которые пилят ядро, чем абы каким быдлокодерам нанятым за еду. Поэтому лучше уж если хевилифтинг сделают они, а не фиг знает какие быдлокодеры, которые неизбежно схалтурят там и тут.
>> Вот мне и не понятно - зачем в этом процессе какие-то левые
>> юзерспейсные демоны вообще будут фигурировать?
> За тем, что MS DOS - это вообще не операционная система. Это "монитор".
Это монитор пытающийся косить под операционку :). Ну, какое-никакое апи оно вывешивало, по поводу чего и "операционка", собственно. Монитор все-таки не занимается предоставлением API программам.
