>Для этого желательно наличие более или менее стабильного ядерного API. А то эти проекты вечно будут ко вчерашним ядрам подходить...

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

>Как вы лихо отсеяли необходимое... :) Некоторым, например, дисковая подсистема не является необходимой. А для некоторых - usb обязательна.

я ж не гвоорю что нужно совсем выкинуть, просто выделить в отдельные пакеты и отделить цикл разработки. Для того же усб можно было б оставить базовую поддержку + UMS, а дрова для всяких гаджетов, модемов и прочей редко-нужно фигни выделить в отдельные пакеты. Как сделано с алсой (не учитывая ту что в ядре) - разрабатывается отдельно, пакеты отдельно, собирается вполне стабильно со всеми ядрамии

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

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

> Ага. Я так и думал что свет клином сошелся именно там. :) А я все время считал ее специализированной ОС для разработки рейлтайм приложений... В каковом качесте она и применяется. В чем я неправ ?

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

вы наверное удивитесь, но под ту-же QNX без особых проблем собирается Qt4 и, при большом желании, поверх оного затачивается KDE. проблемы будут не только и не столько с микроядром [с последним их не будет вообще], сколько с отсутствием некоторых Linux specific интерфейсов -> скорее морока со сборкой. но, тем не менее, соберётся. и отличить KDE, который крутится на BSD, Linux или "microkernel realtime os для специализированных приложений" вы скорее всего не сможете.

> Накладные расходы на переключение контекста при логичном разбиении (ведь это одна из целей проектирования) на процессы ядра. Это если кратко - раз.

как-то не густо с аргументацией. да, достаточно давно решили. и в Linux то-же решили и обе операционные системы тратят вполне вменяемое время на переключение контекста между процессами. ну и что?

> Я в курсе что у вас в QNX эту проблему "почти решили". Кому нибудь еще это удалось ? НЕ в _исследовательских_ операционках.

не понял вопроса. что значит - в других не исследовательских операционках? в хурде, как ярком примере сферического коня в абсолютном вакууме? чес слово не знаю. в QNX, как ярком примере OS, далёкой от "исследовательской"? да, решили.

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

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

> Это я к тому что все подобные ОС исследовались в _упрощенном_
случае, при отстутствии этой кучи. И _проверить_ как оно будет и не возрастет ли на деле сложность разработки при наличие такой кучи в "реальном мире" никто не смог.

упрощённом/куча - это сколько? 10? 100? 1000? 10k? даже под текущую версию QNX AFAIR 6.3 вендором выпущено достаточно много драйверов + 3d party решения. и все они прекрасно себя чувствуют и работают вместе как единая система. не понимаю, что ещё вам требуется доказать? конкретного и более чем работоспособного примера проверенного временем вам мало?

// wbr

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

а по-серьёзному, есть такое выражение "Большая сила - большая ответственность" - это к тому, что возростание популярности и сфер примемения Линукса имеют и обратную сторону в виде нагромождения поддержки кучи железа и тд

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

Заканчивайте говорить о том, чего не знаете. http://en.wikipedia.org/wiki/Ring_(computer_security)

> Заканчивайте говорить о том, чего не знаете. http://en.wikipedia.org/wiki/Ring_(computer_security)

"Ring 1 and Ring 2 are rarely used, but could be configured with different levels of access."

Что и.т.д. Назначение их в теории возможно и ясно, до практики дело не дошло. Внимание, вопрос - почему на меня тогда наехали? :)

>>Внимание, вопрос - почему на меня тогда наехали? :) У меня и в мыслях не было наезжать. Просто начиная с поста "sv75 19.09.2007 15:50:20" идёт какой-то бред.

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

>> Только упростить его пришлось по самое небалуйся и получившиеся интерфесы стали напоминать того самого сферического коня в вакумме.

>Какие интерфейсы вам нужны у ЯДРА??? "Дай ресурс" да "забери ресурс" - вот и все его интерфейсы.

Сферического ядра в вакууме - конечно :)

>То есть книгу ты не читал, но она тебе не интересна. "Это многое объясняет" (c)

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

> Просто начиная с поста "sv75 19.09.2007 15:50:20" идёт какой-то бред.

Там был смайлик. Вам видимо просто не снижали оценку за ответ про "два уровня защиты" (студент-то помнит, что есть kernel/user) вместо "четырех" (как в спецификации i386, surprise!).

> Назначение их в теории возможно и ясно, до практики дело не дошло.

Очень даже дошло, даже сейчас используются.

> Очень даже дошло, даже сейчас используются.

Да, в некоторых ОС, которых в живую никто не видел. Кстати тут выше было новое для меня утверждение про два кольца в amd64. Если это так, то четырее кольца i386 можно считать окончательно умершими...

>Какие интерфейсы вам нужны у ЯДРА??? "Дай ресурс" да "забери ресурс" -
>вот и все его интерфейсы.

Охренеть себе упрощенство. Вообще говоря в данном случае значение имеет не только сам интерфейс наноядра, а как через этот интерфейс _без потери скорости_ вызывать другие ядерные сервисы. Маршаллинг этот долбаный, удобство отладки сервисов с учетом маршаллинга и прочие подобные заморочки.

Почитайте рассылку хурда, очень занимательно.

> В той книге, которую читал (и которая является довольно авторитетной) написано как раз то, что я утверждал.

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

> Охренеть себе упрощенство. Вообще говоря в данном случае значение имеет не только сам интерфейс наноядра, а как через этот интерфейс _без потери скорости_ вызывать другие ядерные сервисы.

системный вызов read/write в никуда [/dev/null] на Linux займёт примерно 1 микросекунду. примерно столько же займёт передача сообщения запрос-приём-ответ в одной небезызвестной OS. это - накладные расходы ядра, все, что дальше - это уже забота кода, который отвечает за обработку вызова. он может исполнятся быстро, может медленно etc но собственно к OS прямого отношения это уже не имеет.

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

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

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

> Почитайте рассылку хурда, очень занимательно.

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

// wbr

> почему вы столь упорно апеллируете к системам, которые дефакто не
> существуют

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

А не шаманский бинарный блоб "который делает всио".

> и полностью игнорируете реально существующие и, что немаловажно,
> работающие и используемые системы?

Лично от меня QNX это система далекая настолько, насколько от вас Хурд. Железо разрабатываемое вокруг меня это вин + чтото типа OS9, Сама фирма-автор от развития QNX в систему общего назначения отказалась - то есть фактически признала как минимум нерентабельность подобного процесса. А используют QNX _гдето_ и _какието_ непонятные люди из интернет :)


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

Потому что достали ушлепки (это я не про вас, специально пишу :) ) в стиле "Ваш линупс это ниправельная ОС а вот МИКРОЯДЕРНЫЕ ОС это мой ФЕТЕШЬ. Я них $^^^&$ ПО НОЧАМ. Бросйте свой линупс и $%^^&$$ ВМЕСТЕ СО МНОЙ"

И я пытаюсь доказать немного не это.

ps: да и собственно возвращаясь как это ни странно к теме оригинального сообщения. AFAIU проблемы, указанные Эндрю, не имеют ничего общего с тем, как именно организована архитектура ядра. будь то микроядро, all-in-one или же что-то среднее - если на группу аудита сваливается непосильный для неё объем работ это в первую очередь означает, что её банально за DDOS-или и уже совершенно фиолетово, какая именно архитектура используется в проекте.

"старый хозяин обычно не кровати двигал, он &^%^ менял.." (c) анекдот.

// wbr

> и это печально, т.к. из версии в версию таскают один и тот же код, который юзают 15-20% пользователей.

М... Ровно до тех пор, пока вы не оказываетесь среди этих процентов. :)

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

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

толку то..

> Лично от меня QNX это система далекая настолько, насколько от вас Хурд. Железо разрабатываемое вокруг меня это вин + чтото типа OS9, Сама фирма-автор от развития QNX в систему общего назначения отказалась - то есть фактически признала как минимум нерентабельность подобного процесса. А используют QNX _гдето_ и _какието_ непонятные люди из интернет :)

тогда IMHO стоит вместо обобщённого "microkernel based OS" указывать конкретную систему, от которой вы отталкиваетесь - Hurd - и в этом случае ваши аргументы против могут обрести какую-то конкретику.

"в Hurd это не работает", "в Hurd то-то и то-то медленно", "в Hurd там-то и там-то через жопу" - это я вполне понимаю. в отличие от "микроядерные OS медленные по определению причём как класс".

> Потому что достали ушлепки (это я не про вас, специально пишу :) ) в стиле "Ваш линупс это ниправельная ОС а вот МИКРОЯДЕРНЫЕ ОС это мой ФЕТЕШЬ. Я них $^^^&$ ПО НОЧАМ. Бросйте свой линупс и $%^^&$$ ВМЕСТЕ СО МНОЙ"

IMHO бессмысленная трата времени.

// wbr

> толку то..

Можно по крайней мере очень уверенно ответить на вопрос "Можно ли написать FOSS микроядерную систему" :) Ответ "Может и можно но крутые перцы пытаются двадцать лет с разными ОС и пока получается какаято фигня."

> тогда IMHO стоит вместо обобщённого "microkernel based OS" указывать
> конкретную систему, от которой вы отталкиваетесь - Hurd - и в этом
> случае ваши аргументы против могут обрести какую-то конкретику.

>"в Hurd это не работает", "в Hurd то-то и то-то медленно", "в Hurd
>там-то и там-то через жопу" - это я вполне понимаю. в отличие от
>"микроядерные OS медленные по определению причём как класс".

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

Если выясняется что в реальном мире конкретных реализации в некоторых условиях, как бы никому сделать не удалось, в случае ОС общего назначения, то с практической точки можно сказать "микроядерная ОС общего назначения наверное не может быить создана в обозримом будущем, так как человечиеский разум задачу _до_сих_пор_ не осилил."

Я постараюсь завтра сформулировать куда в теории теряется время во время некоего обобщенного вызова системного сервиса в микроядерной
ОС. Так как я все таки настаиваю на более общем подходе.

Собственно приводимый контрпример - QNX, страдает тем что
а) достаточно долго он вообще был "только для кастомеров" - то есть проветь как там оно будет "для всех" было не возможно в принципе

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

с) А сколько кстати за вычетом встроенных и специализироанных систем каких нибудь решений на QNX ? Примерно ? А то все таки ОС общего назначения предпологает что ее можно сунуть вовсюда :) Какой нибудь соларис и на десктопах есть, и встроенный/специализированный бывает - а казалось бы, серверная ОС. Как с этим у QNX ?

PS
Все, устал - пошел спать :)

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

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

>линаксу

К логопеду, быдло!

> как-то не густо с аргументацией. да, достаточно давно решили. и в Linux то-же решили и обе операционные системы тратят вполне вменяемое время на переключение контекста между процессами. ну и что?

И то, что без надобностей сискалы рекомендуют не дёргать. Потоков там сотню на процесс создать и хватит, в то время, как чисто userspace радотают десятки тысяч. С сокетами там, не select/poll дёргать, а поинтереснее способами пользоваться. Особенно, в серверах с кучей клиентов. Для pppoe придумали модуль ядра, т.к. гонять гонять пакеты kernelspace - userspace - kernelspace несколько накладно и уже 20-30 пользователей, качающих файло через 600Mz шлюз загружают его до просадки скорости сети. А с модулем - загрузка по нулям... Можно ещё много примеров привести. Например, напомнить недавнюю дисскуссию с участием Торвальдса, на тему "а давайте вынесем драйвера в userspace". И чем это всё кончилось. Здесь же, фактически, то же предлагается...

Но это прозаика. Почему-то все заговорили о микроядре и дружно забыли в чём была суть. Ну медленное переключение контекста, так не надо его делать. Мы сейчас живём (и вполне неплохо) без этого. Да, модуль может вальнуть ядро, что дальше? Надо модули хорошо подбирать, отвал накопителя, на боевом серваке, не менее неприятно, чем его полное падение. Такого просто не должно быть (ни одного, не второго).

А если без переключения контекста, то это путь M$ Singularity. Т.е. микроядро, где ядерные компоненты работают в едином адресном пространстве. А если это снова назвать своими именами, то получится: не важно, микро или монолит, но пусть у нас будет стабильный ядерный API.

Что ж, поскольку я не анонимный, продолжу заниматься аналитикой. :)

Итак, стабильный ядерный API. Что он даёт и чего требует в замен? Следует обратиться к примерам систем, где такое практикуется. Например... к Windows...

Те, кто имел несчастье работать с usb на Windows 95 OSR2 помнят, что вместо usb-стека там одно название, а в Windows NT 4 его даже не пытались реализовать. При это хорошо известно, что драйвер для NT4 не обязательно будет работать в Windows 2000, драйвер (уже WDM) для Windows 2000 не обязательно будет работать в Windows XP, а драйвер Windows XP уже не обязательно подойдёт к Windows XP SP2 и далее, до Vista.

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

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

НО, МИНУТКУ! Ведь взыл не Торвальдс, а Мортон! Т.е. тот, кто возится с нестабильным ядром и стабилизация API которому никак не поможет! То есть проблема вообще не в API. Всё равно кому-то придётся сводить разные части проекта, убеждаясь в отсутствии конфликтов. И объёмы там особенно меньше не станут.

То есть, если -mm стала официальным-неофициальным полигоном для тестирования новых фич и её разработчик зашиватеся под потоком патчей, то логичное решение - реорганизовать процесс её подготовки. Например, чтобы его не терзали поддержкой, а вопросы доходили до авторов проблемного кода и т.д.

А вместо этого пошёл разговор из серии "Как нам реорганизовать РАБКРИН", т.е. как бы нам переделать ядро так, что бы и дальше Мортон пахал один. Ну... Тут ответ один, как в известном анекдоте про солдатскую рационализацию (http://www.anekdot.ru/an/an0209/v020910.html#9): ему надо не только микроядро, надо фару на лоб повесить, чтобы он и ночью ядро собирал и отзывы читал...

> Можно по крайней мере очень уверенно ответить на вопрос "Можно ли написать FOSS микроядерную систему" :) Ответ "Может и можно но крутые перцы пытаются двадцать лет с разными ОС и пока получается какаято фигня."

идея понятна. провальная идея.

> Микроядерные ос базируются на некоторых принципах. Как то вызов сервисов ядра путем посылки и приема сообщений.

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

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

распределение тех или иных подсистем между независимыми процессами и передача управляющих запросов посредством сообщений в первую очередь диктует требование чётко прописывать протокол обмена сообщениями между этими процессами. разбиение же системы на независимые модули с чётко заданными интерфейсами взаимодействия и стандартизация API/ABI в свою очередь действительно заметно упрощает разработку, отладку и в особенности сопровождение ПО.

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

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

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

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

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

впрочем, в отличии от указанного средства передвижения, предмет спора я как раз видел и не раз и могу вас заверить - работает прекрасно в том числе и как десктоп. то же факт, что QNX+Linux+BSD+все вместе взятые дружно сливают банальной XP - это уже совершенно другой вопрос.

> Я постараюсь завтра сформулировать куда в теории теряется время во время некоего обобщенного вызова системного сервиса в микроядерной
ОС. Так как я все таки настаиваю на более общем подходе.

ждем'c. попытки опровержения объективной реальности - это всегда захватывающее зрелище.

> Собственно приводимый контрпример - QNX, страдает тем что
а) достаточно долго он вообще был "только для кастомеров" - то есть проветь как там оно будет "для всех" было не возможно в принципе

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

> с) А сколько кстати за вычетом встроенных и специализироанных систем каких нибудь решений на QNX ? Примерно ? А то все таки ОС общего назначения предпологает что ее можно сунуть вовсюда :)

не понял. приведённое выше - это ваши аргументы в пользу невозможности создания GPOS на основе микроядра? это что - все :-?

> Какой нибудь соларис и на десктопах есть, и встроенный/специализированный бывает - а казалось бы, серверная ОС. Как с этим у QNX ?

десктопный вариант? был всю жизнь от самого рождения. вообще-то, это одна из отличительных черт QNX. включая полнофункциональную среду разработки ПО на базе Eclipse для 6ки.

// wbr

> Те, кто имел несчастье работать с usb на Windows 95 OSR2 помнят, что вместо usb-стека там одно название, а в Windows NT 4 его даже не пытались реализовать. При это хорошо известно, что драйвер для NT4 не обязательно будет работать в Windows 2000, драйвер (уже WDM) для Windows 2000 не обязательно будет работать в Windows XP, а драйвер Windows XP уже не обязательно подойдёт к Windows XP SP2 и далее, до Vista.

AFAIR в то время, когда в Win95 от USB стека было лишь название, небезызвестная система Linux сама по себе была разве что названием но не более.. ;)

что же до стабильности API/ABI - все зависит от частоты смены этого API. если как в случае с Microsoft делать это в среднем раз в пять лет (95-NT-XP-Vista) - это вполне приемлемо. за пять лет железо успеет поменяться десять раз включая шины и интерфейсы и ничего тут не попишешь. ну а если же делать это по поводу и без по несколько раз в год - это уже совсем другой коленкор...

// wbr

> Таким образом, мы видим по крайней мере частичную правоту утверждения, что стабильный ядерный API - нонсенс. Microsoft, сделавший обратную совместимость своим лозунгом и маркетинговым ходом, вынужден премя от времени этот самый API пересматривать. И это при том, что Microsoft имеет доступ к спецификациям, возможность пропланировать своё ядро. А Linux, разработчикам которого часть спецификаций достаётся по случаю, просто не может позволить себе стабилизировать API хотя бы на год-два. В противном случае, именно столько придётся ждать владельцам железок, адекватную поддержку которых будет мешать реализовать этото самый долговременно стабилизированный API.

вот скажите, какая &^%&^$% удалила class_simple_device_add/remove()? в 2.6.9 были а вот в .18 а может и раньше уже нет. они шо, кому-то мешали? причём что времени прошло хрен да маленько и к спецификациям на железо или козням Микрософт они не имеют никакого отношения.

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

// wbr

>>Какие интерфейсы вам нужны у ЯДРА??? "Дай ресурс" да "забери ресурс" - >>вот и все его интерфейсы. > >Охренеть себе упрощенство. Вообще говоря в данном случае значение имеет не только сам интерфейс наноядра, а как через этот интерфейс _без потери скорости_ вызывать другие ядерные сервисы. Маршаллинг этот долбаный, удобство отладки сервисов с учетом маршаллинга и прочие подобные заморочки. Какие другие ядерные сервисы? Кто мешает другим ядерным сервисам общаться на другом уровне защиты? А если они собираются общаться через микроядро - это как раз сведется к ожиданию ресурса (сообщения) от микроядра. Микроядро в принципе только и должно что распределять ресурсы - процессора, памяти, аппаратные порты и обеспечивать их инициализацию при передаче другому потоку и в аварийных ситуациях. Ну возможно несколько сервисных функций для администрирования. И это всё. Даже система полномочий пользователей будет сидеть ниже.

> НО, МИНУТКУ! Ведь взыл не Торвальдс, а Мортон! Т.е. тот, кто возится с нестабильным ядром и стабилизация API которому никак не поможет! То есть проблема вообще не в API. Всё равно кому-то придётся сводить разные части проекта, убеждаясь в отсутствии конфликтов. И объёмы там особенно меньше не станут. То есть, если -mm стала официальным-неофициальным полигоном для тестирования новых фич и её разработчик зашиватеся под потоком патчей, то логичное решение - реорганизовать процесс её подготовки. Например, чтобы его не терзали поддержкой, а вопросы доходили до авторов проблемного кода и т.д.

Вот именно. Как вы будете локализовать проблемный код?? У микрософта сидят сотни и сотни индусов и тестируют драйверы. Дохрена вы знаете таких романтиков, которые будут это делать добровольно нахаляву? И, главное, как они это будут делать? Есть такие средства? Когда-то в 90х появилось отличное средство для тестирования программ на утечки памяти - оно называлось виндовс-НТ. Драйвера на кривизну нельзя проверить пока они сидят в адресном пространстве ядра. Я не хочу видеть в логах сообщения о том, что кернел получил прерывание от APIC и не знает что с ним делать. Я хочу там видеть сообщение, что прерывание от железки такой-то, за которую отвечает драйвер такой-то не было обработано должным образом и по этому драйвер будет убит, железо реинициализировано, и не пишите в команду, занимающуюся ядром, а просто дайте дюлей автору этого драйвера.

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

Принцип-то простой - разделяй и властвуй.

> что же до стабильности API/ABI - все зависит от частоты смены этого API. если как в случае с Microsoft делать это в среднем раз в пять лет (95-NT-XP-Vista) - это вполне приемлемо.

Собсвенно, я отметил, почему для Linux это не проходит. Основных причин две:

1) Спеки открыли "вот сейчас". И как прикажете заранее планировать? Или ждать 5 лет? Боюсь, не много пользователей дождётся... Да и разработчиков. Форк натурально сделают.

2) Реализацию задумывали по открытым, опубликованным спекам, а оказалось, что они, как дока от M$ - практическая реализация иная. В результате N процентов устройств невозможно использовать эффективно с тем, что есть.

> вот скажите, какая &^%&^$% удалила class_simple_device_add/remove()?

Мамой клянусь - не я! :) Боюсь, если никому не мешало - сочли избыточной сущностью...

Поймите, я не против некоторой стабилизации. Но она будет иметь эффект лишь на области стабилизации, что собственно и происходит на 2.6.xx.yy, при постоянном xx... Поэтому от Торвальдса жалоб нет.

> Дохрена вы знаете таких романтиков, которые будут это делать добровольно нахаляву?

Да, говорят, гентушников не мало... ;-)

> И, главное, как они это будут делать? Есть такие средства?

Классические: запустил - не работает - послал баг репорт.

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

В этом есть рациональное зерно. :)

> Принцип-то простой - разделяй и властвуй.

Собственно, Мортон тонко намекает, что его заколебало получать тонны писем, которые должны попадать к авторам соответсвующего кода. Как это организовывать - вопрос сложный. Но, в целом, мне симпатизирует вариант от M$/KDE/etc... Т.е. что-то упало - анализ дампа на предмет *что* упало, предложение отправить инфу разработчику.

> запустил - не работает - послал баг репорт.

Что запустил? Я вот тут давеча пример из своего компутера приводил. Запустил, пишет в лог: "kernel: [254744.692000] APIC error on CPU0: 40(40)"

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

> что-то упало - анализ дампа на предмет *что* упало, предложение отправить инфу разработчику

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

> НА ЧТО ВЫ ТРАТИТЕ ВРЕМЯ? На ерунду - на написание стотыщного клиента для почты, да прикручивание костылей к дерьму вроде php. Переходите на перспективные системы - РАЗВИВАЙТЕ ИХ! QNX, Bluebottle, Minix-3 - вот достойные детища.

Да говно эти микроядерные системы. Читай вон доку от RedHat про суперпроизводительность Linux и то как микроядерные ОС сосут, если бы они не сосали, то использтвались бы на суперкомпьютерах. Предлагаете устранять недочеты стотыщной системы куникс, миникс или какой-то блуботл, которые(ну разве что специфического применения qnx) все равно никому не нужны? Нах это нужно когда уже есть Linux? У Minix было время развиться, у Hurd. Где они? Правильно, в жопе. Поэтому не тратьте время на всякую херню и не ипите моск, а занимайтесь улучшениями нормальной ОС Linux - это более полезно, чем играться в бирюльки с лабораторными ОС.

> Забудьте хоть на минуту про свои "настроенные" линуксы - ЭТО КОПРОФИЛИЯ! Мусор, хоть и покрашеный красиво, остаётся мусором. Система ls | grep | other_shit устарела как подштаники Торвальдса - мы живём в сильно изменившемся мире медиаконтента.

Закончил пердеть в лужу? А теперь претензии по пунктам.

> И сами ОС должны строиться в соответствии с сильно динамичными требованиями, т.е. быть модульными, способными быстро изменяться. Что есть Линукс?

Линукс - модульная система.

> Разве вы этого не видите? Положите силы на перспективные ОС - они стократно окупятся. Скины - они не окупаются.

На твоих недоос запустится Oracle? А линуксовые драйвера? А eDir? а Lotus? А кто будет это портировать и переписывать? Ты? Фперед - на амразуры.

Linux goes ahead boldly

Stop talking and listen to me, children!

I'm tired of your chattering! You had better try to build your own kernel. Otherwise, go 'ftopku' as some of us like to say. By the way, my best wishes to your president Vladimir Putin. His proposal about nanokernel seems to be very interesting.

Best Regards, Linus Torvalds

> А из линуксоидов на проблемы с изменением интерфейсов ядра реально ругаются только те, кто вынужден пользовать закрытые или полузакрытые поделки типа nvivdia.ko, fglrx.ko и "драйверы" для ублюдочных недоRAIDов.

Ну т.е. практически 90% всех линуксоидов у кого граф. плата не от интел?

> У линукс - монолитное ядро.

Модульное монолитное ядро, а не классическое монолитное.

> А микроядро, к примеру, у мастдая.

У маздая гибридное.

> И ты думаешь, они нигде не используются, раз они не используются в виндоусе и линуксе?

В AMD64 только два кольца защиты, остальные выкинули за ненадобностью. :)

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

> А что, так часто можно встретить линуксоида, способного спокойно, без демагогии и наездов на оппонента воспринять информацию о том, что линукс далеко не так стабилен как виндовус?

Очень редко, потому что это неправда.

> Если бы не ряд публикаций, некоторые товарищи тут бы просто на говно исходили бы доказывая безбажность линукса и что разработка линукса идет правильным путём под верным руководством мудрых товарищей ;-)

Для того, чтобы понять как стабильны Linux-сервера нужно читать книжные публикации?

> и это печально, т.к. из версии в версию таскают один и тот же код, который юзают 15-20% пользователей. Просто ядро потихонько превращается в неповоротливого монстра. 40мб тарбол это весьма порядочно и не всегда нужно

Ты сам собираешь себе ядра? Загружаешь одновременно все модули? Или страдаешь от того, что собранное ядро занимает 15 мегабайт, большая часть модулей которого не загружена в ОЗУ?

>> Дело не в ресурсах, дело в том что это монолитное ядро. Проблемы совершенно понятные. Я уже давно на всех форумах говорю, что так дальше нельзя. Надо переходить к микроядру. >> Мой прогноз: если от модели монолитного ядра не откажутся у ядра плохое будущее. Надо принимать волевые решения, а не почивать на лаврах.

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

Ты видимо ни разу не участвовал в разработке проекта, где хотя-бы 20-30 тысяч строк кода.

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

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

Хотя опять-же, зачем писать, взять тот-же Mach, оживить MkLinux, и продолжить развивать..

> А если без переключения контекста, то это путь M$ Singularity.

Не говори M$ Singularity, говори OS Inferno. И думаю, вполне жизнеспособный подход: часть работы тупого процессора берёт на себя умный компилятор.

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

Они умеют писать ядра лучше ветеранов этого дела, ага.

> зачем писать, взять тот-же Mach, оживить MkLinux, и продолжить развивать..

Таких, как ты, называют "armchair coder" (что-то вроде "пикейного жилета").

P.S. я ничего не имею против микроядер и userspace-драйверов с технической точки зрения.

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

Чем меньше код, тем менше вероятность ошибки. А таковые могут произоити не только по вине программиста, но и например из-за железа. Поетому микро ядро с точки зрения елементарной теории вероятности гораздо надёжнее монолита. В своё время етот аргумент был в ползу линукса vs. M$ XP.

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

Не согласен. Узкое место - межпроцессная синхронизация посоредством именнованых семафоров. В Линухе в именнованой шаред мемори нельзя создать неименованный POSIX семафор.

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

Да уж.. пальцем в небо. Берём драйвер для железки написанный под 2.6.8, думаю к 2.6.20 он уже не подойдёт. А если драйвер идёт ввиду бинарника?

Когда драйвер написанный для 2.6.x не совместим с версией 2.6.y можно считать, что критическая масса набрана. Жалобы второго человека среди разработчиков ядра - не формальное признание проблемы.

> В Линухе в именнованой шаред мемори нельзя создать неименованный POSIX семафор.

Хм, не догоняю - зачем создавать семафоры в разделяемой памяти?

Только так можно синхронизировать процессы в qnx4 и так можно в qnx6. Это к вопросу о том, что весь код почти без переделки легко перекомпилируется под Линуксом. Я к тому, что не легко.

> Да уж.. пальцем в небо. Берём драйвер для железки написанный под 2.6.8, думаю к 2.6.20 он уже не подойдёт.

Почти наверняка. Но сколько лет прошло между .8 и .18? Как минимум это цикл RHEL по времени.