> Для особо одарённых и внимательных слушателей: при авариях такого рода от формальной проверки кода нет никакого толка.

Да неужели? И у тебя есть примеры сбойнувшего _верифицированного_ софта? %) Я так и думал.

> Устарел для чего и по сравнению с чем?

Для всего. По сравнению с современными языками. // К.О.

Или вы всё ещё собираетесь на ФП писать ОС ?

Кто «мы»? Я вообще не собираюсь писать ОС.

Но всё идет к тому, что ОС следующего поколения (если они появятся) будут написаны на чем-нибудь вроде C#, BitC, Ivy, Cyclone.

Имхо, не в языках проблема,

а в том, что в индустрии ПО, и не в последнюю очередь благодаря девизу оупенсорсников «релизь раньше, релизь чаще», подменяется качество кода его количеством. И в том, что для большинства нынешних программистов прототипирование не только опережает, на часто и заменяет проектирование. Зачем продумывать и контролировать работу с памятью если есть сборщик мусора? Зачем писать корректный код, если можно получить деньги второй раз за рефакторинг? Именно потому, что программирование из искусства стало ремеслом для недоучек, которым даже в алгоритмах лень разбираться (действительно, зачем знать географию если есть извозчики, пардон, таксисты?). Воистину, если бы здания строились как пишутся программы, первый воробей разрушил бы цивилизацию...

.......
P_критическое = 0.04
.......
если  p < P_критическое делай то
иначе делай это
......

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

Да неужели?

Ну и как тут поможет верефикация абсолютно верного кода?

Зачем продумывать и контролировать работу с памятью если есть сборщик мусора?

Кстати, да. А зачем?

> а в том, что в индустрии ПО, и не в последнюю очередь благодаря девизу оупенсорсников «релизь раньше, релизь чаще», подменяется качество кода его количеством.

Вообще-то у опенсорса «релизь раньше, релизь чаще» - это способ достижения именно _качества_. А вот у «индустрии» это способ заработать денег.

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

Дятел, не воробей. Попробуй вспомнить, когда эту шутку придумали.

> это способ достижения именно _качества_

А где оно - качество? Кругом бесконечные пре-альфы, альфы и беты - а как ни релиз, так мешок багов и багофич («так было задумано») в комплекте.

Дятел, не воробей. Попробуй вспомнить, когда эту шутку придумали.

А зачем вспоминать? Принципиально ничего не изменилось, люди остались те же. Вон, «практики» уже отметились в стиле «всё бы хорошо, кабы не заказчики-редиски»...

>> это способ достижения именно _качества_

А где оно - качество?

Какое качество тебе нужно? У меня на десктопе опенсорсное ПО, я с помощью него зарабатываю на жизнь. Так что качество опенсорсного ПО лично я считаю приемлимым.

А зачем вспоминать? Принципиально ничего не изменилось, люди остались те же.

Ну то есть твои слова сводятся к «и опсорс, и индустрия ПО всегда делали говно». И... какой вывод (если вывод есть)?

> Какое качество тебе нужно?

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

какой вывод (если вывод есть)?

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

>А где оно - качество? Кругом бесконечные пре-альфы, альфы и беты

«Кругом» - это в ваших слаках, гентах и арчах. В номальных дистрибутивах - качество вполне приемлимое.

Как начавший со слаки и ушедший на Fedora/CentOS скажу - везде не торт. Либо функционально но нестабильно, либо стабильно но версии древние. И именно как вы сформулировали - из доступного ищется «вполне приемлимое», вместо качественного.

>> Какое качество тебе нужно?

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

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

Вывод - что без грамотного _проектирования_ софта, никакой супер-пупер-надежный-и-безопасный язык от багов в этом софте не спасёт

А кто-то говорил, что спасет? *shrug*

Пример грамотно спроектированного софта без багов ты привести можешь?

> Список известных багов в Linux-ядре

перечислять смысла не вижу.

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

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

Вывод - что без грамотного _проектирования_ софта

хех. мне вот интересно, что ты под этим понимаешь, когда
речь идет о проекте такого масштаба.

И вот тут к сожалению «базарный» метод разработки

оказывается как бы не на коне

а что на коне?

такое впечатление, что ты знаешь ответ, но не хочешь
отрыть нам глаза.

>Либо функционально но нестабильно, либо стабильно но версии древние.

Замени «новые версии» на «нестабильные версии» и ты сам ответишь на свои вопросы.

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

Там была проблема с конверсией значения с плавающей точкой к 16-битному целому. Проверить выход за пределы представления достаточно просто, зная диапазон входных значений (который буквально прочитывается в паспорте соответствующего датчика).

Сенсация!!!

Сенсация!!! Известный в узких кругах Хакер Василий Коркин , в дальнешем ВК, (codename Zer0cool) через выявленную, невыявленную, но тут же выявить, дырку в двери, окне, стене и т.п.(фантазии заказчика приветсвуются), может добраться и уронить (без ковычек) любой компьютер (кол-во обговаривается с заказчиком), причем установленная ОС не столь Важна, можна даже без ОС, за что и получил ВК свой ник Zer0cool что в переводе означает - Дыра, ето круто!

В прошлом ВК был медвежатником, но в местах не столь отдаленных заинтересовался Системным блоками, Мониторами и ОС которые можно ронять и получать за ето не плохие деньги, причем стятья за ето идет всего лишь Хули-ганство (ганство - сокр. ганстерство)......

зная диапазон входных значений

тут-то собака и порылась.

прочитывается в паспорте соответствующего датчика

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

> А если заказчик был неправильно понят? Очень тяжело понять, что можно сделать, если ты не программист. По научным программам знаю, которые убоги.

Это как раз ещё одна причина, почему ТЗ должно писаться совместно. Иначе можно получить ТЗ вида

«Нужна программа для ведения бухучета с интерфейсом, соответствующим требованиям эргономики, и обеспечивающая соответствие введённых данных требованиям законодательства РФ.».

>>ну это как минимум непрофессионально основывать суждение по надписям, а как же содержание?

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

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

+1
используй что больше нравится

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

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

> Вон, «практики» уже отметились в стиле «всё бы хорошо, кабы не заказчики-редиски»...

Кто девушку ужинает, тот ее и танцует!

>>Замени «новые версии» на «нестабильные версии»

с какого перепуга?
или это аксиома опенсурсЪ?

собрал под cygwin, запустил. скушало 100% одного ядра, умудрилось занять аж 91 дескриптор. убил безо всяких проблем.

> По крайней мере, есть гарантия от того, что один модуль портит память другого.

Нет такой гарантии. Как модули между собой будут общаться, кроме как через shared memory? И как в микроядре модули должны работать с оборудованием?

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

> А если сети, USB или видео?

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

Примерно такая же ситуация и с видео, за исключением того, что демоны не упадут. Фактически, сейчас все так и происходит без всяких микроядер: в случае глюка в модуле видео - он вместе с Х-ами падает и затем перезапускается.

> Микроядро не является «серебряной пулей», но многие проблемы всё же решает.

А решает ли оно вообще хоть одну проблему? Кода будет больше, сам код будет сложнее, медленнее и труднее в отладке. А что улучшится? Вот, скажем, как бы микроядро помогло в случае сабжа? А то ведь защита разных областей памяти и в обычном linux-ядре есть.

Этот ваш вирус:
Под QNX 6.2.1, FreeBSD 6.0 -тупо вылетел с ошибкой -1 или -2;
Под Solaris 10 5/09 - убивается по ^C;
Под Linux SuSE 9.2 (ведро 2.6.8) - все заметно припаривает и тормозит, но тоже убивается контролом-Цэ.

Выводы:

1. Нонешнее ведро спопсилось и скатилось в сраное гамно;
2. Нонешние т. н. хакеры - имбецилы;
3. main(){for(;;)fork();} /* Тоже типа вирус, похлещще здешнего */

>> По крайней мере, есть гарантия от того, что один модуль портит память другого.

Нет такой гарантии.

Афигеть. Вот просто так «нет». Потому что ты сказал, да? И ntfs-3g может завалить ядро (за счет своих собственных багов, не ядерных)?

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

По твоей ссылке Линус говорит то, что он всегда говорил - общеизвестные вещи, разбавленные FUD.

Как модули между собой будут общаться, кроме как через shared memory?

1) Даже если они общаются через shared memory, их критические данные отнюдь не там; 2) есть и другие средства IPC

И как в микроядре модули должны работать с оборудованием?

Usermode-драйверы Linux реализуемы и реализованы, см. проект Gelato: http://lwn.net/Articles/66829/

А если сети, USB или видео?

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

Это эквивалентно потере коннекта у клиентов, что случается и и без ошибок в драйверах. Что характерно, ты не ответил насчет видео и USB.

Микроядро не является «серебряной пулей», но многие проблемы всё же решает.

А решает ли оно вообще хоть одну проблему?

Да. Они решают проблему взаимовлияния компонентов ядра на уровне Си. Любой, кто писал ядерный код, это понимает. Ситуация из практики: отлаживаемый драйвер делает kfree на неправильном указателе, и в результате отваливается autofs (драйвер ни к сети, ни к ФС отношения не имеет вообще). Представь, что ошибка не проявится на стадии отладки.

Кода будет больше,

Ненамного.

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

Ты когда последний раз драйвер отлаживал?

Вот, скажем, как бы микроядро помогло в случае сабжа?

В Ъ-микроядре можно было бы прибить сервер, реализующий Unix-сокеты.

Буду краток. Патч ждать?

можете не ждать - пусть он сам нагрянет внезапно :)

> И ntfs-3g может завалить ядро (за счет своих собственных багов, не ядерных)?

Во FreeBSD и в OpenSolaris - может. Сейчас ты будешь возражать, что это был баг FUSE, а не ntfs3g, я знаю. Это ничего не меняет. Появление FUSE не уничтожило магическим образом все баги. Просто переложило поиск проблемы в другое место. Цена этого - тормоза, ntfs3g даже на 8-ядерных CPU не может использовать больше одного ядра.

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

> По твоей ссылке Линус говорит то, что он всегда говорил - общеизвестные вещи, разбавленные FUD.

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

> 1) Даже если они общаются через shared memory, их критические данные отнюдь не там; 2) есть и другие средства IPC

Ок. Тогда это еще больше затруднит их взаимодействие, потому что, например, один драйвер не сможет иметь общие блокировки с другими драйверами. Кстати, как без shared memory можно передать буфер, например, при вызове функции write?

> Usermode-драйверы Linux реализуемы и реализованы, см. проект Gelato

Ну да. Давайте вынесем драйвера в userspace, а потом... дадим им доступ на запись в pci и /dev/mem... Так что там про то, что один драйвер не сможет испортить память другого? ;)

> Это эквивалентно потере коннекта у клиентов, что случается и и без ошибок в драйверах.

А что это будет для UDP-сокетов? А что будет, если все Х-клиенты потеряют соединение с Х-сервером?

> Что характерно, ты не ответил насчет видео и USB.

Про видео - ответил. А падение USB и сейчас ни на что не влияет. Максимум - мышь отвалится, придется вытащить и вставить обратно. В смысле, это все и сейчас есть.

> Они решают проблему взаимовлияния компонентов ядра на уровне Си.

Например? Можно какой-нибудь пример, который не реализован еще в ядре линукса, но оформление которого в виде отдельного сервиса решило бы «проблему взаимовлияния»? Какой из существующих драйвером можно таким вот образом вынести из ядра?

> В Ъ-микроядре можно было бы прибить сервер, реализующий Unix-сокеты.

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

> Usermode-драйверы Linux реализуемы и реализованы, см. проект Gelato: http://lwn.net/Articles/66829/

«Реализованы» - это громко сказано. Где они реализованы? Я вижу только статьи и идеи. Опять какая-то академическая выдумка...

> Ситуация из практики: отлаживаемый драйвер делает kfree на неправильном указателе, и в результате отваливается autofs

У меня - ноль внимания: http://pastebin.ca/2007117 Не падает, не ругается. Словно ничего и не было.

> Ненамного.

До тех пор, пока драйвер - это просто пример. В реальности все сложнее. Например, если я пишу драйвер, который читает время в CMOS-е (пример из minix-а), как мне гарантировать, что никакой другой модуль в это же время не начнет писать в 70й порт, чтобы, например, считать параметры оборудования?

> Ты когда последний раз драйвер отлаживал?

Пример выше - не считается? ;) Недавно надо было прикрутить регулировку яркости для неподдерживаемой ядром модели ноутбука. Написанный на коленке маленький модуль ядра решил проблему. А ты? А что?

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

http://ru.wikipedia.org/wiki/%D0%90%D0%B2%D0%B0%D1%80%D0%B8%D1%8F_%D1%80%D0%B...

Отсюда вывод: программеры взяли старый код (протестированный на старой системе) и тупо прикрутили к новой без системного тестирования/моделирования. Потому что входные параметры для старого кода в новой системе очевидно стали другими (и что, трудно им было догадаться - что другими? и что надо новые тесты для старого кода писать?). Иными словами код верефицировали-варифицировали да не выверифицировали (когда надо было сделать автоматическое тестирование по Кенту Беку - кстати, и это тоже не панацея, тесты ещё надо уметь писать, чтобы не протекали). Ни одна технология не спасает от кривых рук.

>До тех пор, пока драйвер - это просто пример. В реальности все сложнее. Например, если я пишу драйвер, который читает время в CMOS-е (пример из minix-а), как мне гарантировать, что никакой другой модуль в это же время не начнет писать в 70й порт, чтобы, например, считать параметры оборудования?

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

Сервисы, имеющие доступ к оборудованию, будут работать в привилегированном режиме. Остальные сервисы и драйверы - в режиме пользователя.

>Ок. Тогда это еще больше затруднит их взаимодействие, потому что, например, один драйвер не сможет иметь общие блокировки с другими драйверами.

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

Кстати, как без shared memory можно передать буфер, например, при вызове функции write?

shared memory и микроядро не взаимоисключают друг друга. Макроядро - это система процессов, которым доступна вся память системы. Микроядро - это система процессов, в которой ко всей памяти имеет доступ только очень ограниченное число процессов. Большинство процессов в микроядре не будут иметь доступа ко всей памяти, за счёт этого повышается надёжность.

В системах с макроядром shared memory - это выделенные блоки памяти, каждый из которых доступен только определённой группе процессов. Процессы не могут писать (или читать) чужие блоки shared memory. В то же время процессы, работающие внутри ядра по прежнему имеют доступ ко всей памяти без исключения.

В системах с микроядром доступ ко всей памяти будет иметь небольшое количество процессов, а все остальные процессы будут иметь возможность общаться посылкой сообщений через микроядро либо обмениваться информацией через блоки shared memory. Но каждый блок shared memory будет доступен строго ограниченной группе процессов.

Ну да. Давайте вынесем драйвера в userspace, а потом... дадим им доступ на запись в pci и /dev/mem... Так что там про то, что один драйвер не сможет испортить память другого? ;)

Вынесем драйвера в userspace, в kernelspace оставим только менеджер ресурсов. Все драйверы могут обращаться к ресурсам только через микроядро, посылкой сообщений менеджеру ресурсов. Менеджер ресурсов хранит у себя таблицу захваченных каждым драйвером ресурсов и не даёт воспользоваться любому из драверов чужим ресурсом.

Например? Можно какой-нибудь пример, который не реализован еще в ядре линукса, но оформление которого в виде отдельного сервиса решило бы «проблему взаимовлияния»? Какой из существующих драйвером можно таким вот образом вынести из ядра?

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

Что можно вынести в userspace: подсистему TCP/IP, VFS и драйверы файловых систем, видеодрайверы, сетевые драйверы, драйверы дисков и т.д.

Потому что входные параметры для старого кода в новой системе очевидно стали другими
очевидно

Ландау? Не узнаю вас в гриме.

> в userspace: подсистему TCP/IP

TCP/IP в юзерспейсе: новый уровень DDOS!

>TCP/IP в юзерспейсе: новый уровень DDOS!

Да, отказ в обслуживании большим количеством пакетов синициировать будет легче. Но ошибки обработки пакетов в стеке TCP/IP не повлияют, например, на работу дисковой подсистемы.

Когда говорят о каких-то преимуществах, само собой есть и недостатки. Сейчас операция переключения контекста процессора дорогостоящая. Но, подумайте о будущем - уже сейчас ясно, что получат распространение многопроцессорные системы. В них переключение контекста размазывается на все процессоры системы. Насколько в них дорого обойдётся микроядро - никто определённо сказать не может. Я думаю, что если издержки окажутся не более 10%, то уже имеет смысл использовать микроядерные системы.

>Пример выше - не считается? ;)

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

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

> В них переключение контекста размазывается на все процессоры системы.

По-моему это не зависит от числа процессоров. Сейчас TCP/IP работает в любом контексте, а будет --- не в любом, и в возможно только после переключения контекстов (если все потоки TCP/IP сняли с шедулера). То есть всё будет хорошо, если число процессоров примерно равной числу желающих работать потоков.

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

>По-моему это не зависит от числа процессоров. Сейчас TCP/IP работает в любом контексте, а будет --- не в любом, и в возможно только после переключения контекстов (если все потоки TCP/IP сняли с шедулера).

Если программа делает системный вызов, автоматически происходит переключение контекста. Это справедливо и для систем с макроядром и для систем с микроядром. Количество системных вызовов что там, что там одинаково.

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

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

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

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

В общем-то, будет примерно то же самое, что уже произошло с DOS, произошло с классической MacOS, что сейчас потихоньку происходит с Cisco IOS. Это всё примеры систем, надёжность которых основывается на взаимном доверии программ друг другу. Отказ в любой из программ в этих системах мог привести к краху всей системы. Сейчас отказ в любом из модулей ядра может привести к краху всей системы. Вот и вся разница.

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

Это называется load average и сделанный вывод справедлив и для систем с макроядром.

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

Сообщения - это сообщения, они выгодны для быстрой отправки небольшого количества информации. Не обязательно передавать гигабайты информации через сообщения. Механизм shared memory от использования сообщений не упраздняется, через него выгодно будет передавать большие объёмы информации.

>> И ntfs-3g может завалить ядро (за счет своих собственных багов, не ядерных)?

Во FreeBSD и в OpenSolaris - может. Сейчас ты будешь возражать, что это был баг FUSE, а не ntfs3g, я знаю.

Именно так.

Это ничего не меняет. Появление FUSE не уничтожило магическим образом все баги.

Это меняет всё. Теперь ядро могут завалить только баги в FUSE, а не в 100500 файловых системах, написанных поверх нее.

По твоей ссылке Линус говорит то, что он всегда говорил - общеизвестные вещи, разбавленные FUD.

Таки да, это - общеизвестные вещи, и я о том же.

Болтовня и FUD. А в ядре тем временем появляются FUSE и UIO, что как бы намекает на то, что людям это нужно.

Это эквивалентно потере коннекта у клиентов, что случается и и без ошибок в драйверах.

А что это будет для UDP-сокетов? А что будет, если все Х-клиенты потеряют соединение с Х-сервером?

Ты не понял. «Потеря коннекта» в данном случае эквивалентна временному разрыву физического соединения. Т.е. драйвер падает, пакеты перестают доходить, драйвер перезапускается, делается повторная передача пакетов, и приложение видит всего лишь паузу. Для UDP - происходит реальная потеря пакетов, но UDP-приложения должны быть рассчитаны на это. Иксовые клиенты, работающие по TCP, замечают вышеописанный лаг.

Они решают проблему взаимовлияния компонентов ядра на уровне Си.

Например?

Тебе нужен пример того, что один процесс не может испортить данные другого?

Можно какой-нибудь пример, который не реализован еще в ядре линукса, но оформление которого в виде отдельного сервиса решило бы «проблему взаимовлияния»?

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

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

Такой гарантии и в текущем ядре нет.

падение USB и сейчас ни на что не влияет.

Речь не об абстрактных «падениях» (что вообще такое «падение» для драйвера - просто куска кода в пространстве ядра?). Речь о том, что ошибка в USB может стать фатальной для _всей системы_.

Ты когда последний раз драйвер отлаживал?

Пример выше - не считается? ;)

Нет.

А ты? А что?

А я сегодня. Насчет «а что?» - ты как-то смело выдаешь фразы про «академическе выдумки» и «в реальности», при том, что путаешь общую память и shared memory.

P.S. я не поклонник микроядерного дизайна. Но, пока ядра пишутся на Си, чем меньше кода будет выполняться в одном адресном пространстве с ядром, тем лучше для надежности. Конечно, всё имеет свою цену, но я считаю, что вынесение из ядра драйверов и ФС вполне оправдано с точки зрения SE и здравого смысла. VMM, VFS, сетевые протоколы, вещи вроде контейнеров и прочего вполне могут оставаться в ядре - им и правда необходима общая память. Но драйверы и ФС - вещи вполне независимые.

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

Не будем говорить абстрактно. Вот пример кода не для какого-то теоретического идеального микроядра, а для реального: Example 3: CMOS System Clock Там есть вызовы sys_inb и sys_outb. Каким образом гарантировать то, что никакой другой сервис, который, например, читает параметры оборудования из CMOS, не вызовет в это же время sys_outb в тот же порт? Какой будет правильная реализация такого кода?

> Когда говорят о каких-то преимуществах, само собой есть и недостатки.

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

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

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

> Это меняет всё. Теперь ядро могут завалить только баги в FUSE, а не в 100500 файловых системах, написанных поверх нее.

Не забываем про цену. Цена такого решения: невозможность использовать несколько ядер, и потеря скорость в 5-10 раз даже в случае одного ядра. Это хорошо для всяких sshfs, fuse-smb и curlftpfs, где важна не скорость, а функции. Но совершенно недопустимо для основных файловых систем.

Болтовня и FUD

Согласен. Все это микроядро - болтовня и FUD. :)

А в ядре тем временем появляются FUSE и UIO, что как бы намекает на то, что людям это нужно.

Наоборот. Это намекает на то, что идеи микроядра никому не нужны, вероятно, потому, что они не работают. FUSE ни коим образом не подтверждает, что надо что-то выносить из ядра. Наоборот, FUSE - это ЕЩЕ ОДИН МОДУЛЬ ЯДРА. Это и до FUSE было возможно, через LD_PRELOAD, например. Просто FUSE удобнее.

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

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

Как новый перезапущенный драйвер узнает, куда посылать пакеты, отправленные по сокету с socketid 174? Все открытые дескрипторы перестанут работать. То есть придется перезапускать все приложения, которые открывали сокеты. Это и есть ребут.

Тебе нужен пример того, что один процесс не может испортить данные другого?

Нет, мне нужен пример той проблемы, с которой должно бороться микроядро. Не абстрактное «влияние», а конкретная проблема. Я пока не вижу ни одного примера такой проблемы. А то мы долго можем сравнивать сказку (микроядро) с реальностью (линукс) и доказывать, что сказка лучше. Может пора переходить к более реальным аргументам?

И почему тебе обязательно нужен «не реализованный»?

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

Такой гарантии и в текущем ядре нет.

В текущем ядре миникса? Возможно и нет. А в ядре линукса - есть.

Речь не об абстрактных «падениях». Речь о том, что ошибка в USB может стать фатальной для _всей системы_.

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

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

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

> В общем-то, будет примерно то же самое, что уже произошло с DOS, произошло с классической MacOS, что сейчас потихоньку происходит с Cisco IOS. Это всё примеры систем, надёжность которых основывается на взаимном доверии программ друг другу. Отказ в любой из программ в этих системах мог привести к краху всей системы. Сейчас отказ в любом из модулей ядра может привести к краху всей системы. Вот и вся разница.

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

То есть в данном случае это «доверие» обосновано. Остальные не могли таким похвастаться.

> Если программа делает системный вызов, автоматически происходит переключение контекста.

Я про TCP SYN flood! Пррблема не в ситемных вызовах, а в колбаках (в случае мирокядра) в юзерспейс.

> Цена такого решения: невозможность использовать несколько ядер, и потеря скорость в 5-10

Кто и как мерял?

раз даже в случае одного ядра.

Я дро - в смысле вычислительное, core? Никакого отношения к рассматриваемому вопросу это не имеет, userspace-программы отлично параллеляться.

FUSE ни коим образом не подтверждает, что надо что-то выносить из ядра. Наоборот, FUSE - это ЕЩЕ ОДИН МОДУЛЬ ЯДРА.

Ну, с такой логикой тебе в церкви работать.

А UIO - это не то. Это просто интерфейс для работы между ядром и userspace.

Внезапно, интерфейс пользовательских драйверов (описанный в статье, ссылку на которую я давал) - это тоже интерфейс между ядром и userspace.

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

Как новый перезапущенный драйвер узнает, куда посылать пакеты, отправленные по сокету с socketid 174?

Ему скажет ядро (ага, то самое, которое не упало).

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

Я не говорю про микроядра - только про userspace-драайверы и ФС. Пример проблемы, невозможной с userspace-драйверами, я уже привел - сбои autofs из-за неправильной работы драйвера левого character device.

В текущем ядре миникса?

Про миникс знаю мало.

А в ядре линукса - есть.

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

Речь не об абстрактных «падениях». Речь о том, что ошибка в USB может стать фатальной для _всей системы_.

Да. И в случае микроядра ошибка в USB тоже может стать фатальной для всей системы

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

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

Их больше не на чем писать.

Пока не на чем. Но работа ведется.

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

Какая экзальтация. Так и хочется спросить «Сколько тебе лет? (c)»

> Пррблема не в ситемных вызовах, а в колбаках (в случае мирокядра) в юзерспейс.

Какие еще коллбэки? TCP-сервер же %)

Или TCP будет в виде тредов, заснувших на вызове get_eth_frame?

Предлагают вынести TCP из ядра. Работа с железом — в ядре. Итог: SYN пакет по прибытии переходит в юзерспейс. Полагаю, колбеком («к нам тут пакет какой-то, срочно разберитесь»).