Windows NT kernel vs. Linux kernel

//извини за аналогию из процедурного кошмара

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

2. есть вызов процедуры С(все нужные для выполнения аргументы монопольно принадлежащие С- т.е либо копии либо синглтоны - в любом случае пока процедура С не заверширится гарантируется что другие исполнители никак не поменяют «личное окружение С») - в этом случае С может себе позволить выполнится когда угодно.

короче смотри сети петри.

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

можно, только в рекламных целях делают ....

ну смотри

есть натуральные числа== чётные и нечётные.

произведение чётных всегда чётно.

произведение нечётных всегда нечётно.

у продовца только нечётные.

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

прямо заявлять при каких условиях это возможно он не рискует.

поэтому его заявления таковы:

a) я продаю натуральные числа. б) существуют такие натуральные чьё произведение чётно.

95% покупателей уверяются что в асортименте продавца найдётся пара чьё произведение чётно.

----------------- PROFIT

ну я об этом и говорил в общем-то. В ядре nt функции НЕ являются «нормальными», со своим контекстом, как ты описал C(). Похоже их пытались сделать, но не получилось. Получилась НЁХ, не рыба не мясо. Ну и придумали термин «гибридное», хотя НЁХ мне нравится куда больше.

в ПТУ именно сказкам и учат

Во-первых, речь идёт о внутриядерной структуре, а не о сисколлах. Изнутри ядра unlink() не принято юзать.

Во-вторых, внутри ядра вызов функции может быть (очевидно) только внутри нулевого кольца, а сообщения в теории можно передать куда угодно. Другое дело, что NT не использует другие кольца, следовательно, профита от гибридности там 0.

ИМХО в русском языке полно слов, что-бы описать такую торговлю. Но за любое снимут скор, а у меня его и так мало.

во первых unlink просто для примера.

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

Именно, если за пределы нулевого кольца не выходить, то основная разница — в том, что «сообщение» в общем случае тормозит больше. Вывод: NT сочетает недостатки монолитного ядра (всё в 0 кольце) и микроядра (работает чуть медленнее, впрочем, не так медленно, как настоящее микроядро Может, это и есть причина, по которой не стали выносить драйверы на другие кольца. А всю эту фигню с сообщениями запилили по другим причинам).

согласен.

Вангую, что причина проста: хотели как лучше, а получилось как всегда. Спроектировано было всё правильно, внутренние эл-ты должны были обмениваться настоящими сообщениями, которые несут в себе весь контекст и не прибиты к глобальному контексту (в т.ч. и по времени, т.е. выполняются асинхронно. А тот кто послал сообщение может ждать, а может и не ждать его обработки). Однако, в те далёкие годы процессоры были настолько слабыми, что сделать это не получилось, и пришлось таки делать глобальный контекст и синхронность. Скорее всего основная беда была с видеосистемой, которую и пришлось ввести в «микро» ядро. Ну и в итоге стало оно совсем не микро, за то работало на i80486.

Но самое поганое в том, что эта НЁХ из 80х годов прошлого века до сих пор живее всех живых.

в ПТУ именно сказкам и учат

Наверное тебе виднее, но я не могу понять о чём ты говоришь. При чём здесь ПТУ? Или я что-то пропустил в этой ветке?

Не думаю что сравнение технической литературы со сказками корректно.

зависит от того на кого литература(некоторого жанра) ориентирована

техническая литература разнообразна.

те же 21Days несколько отличны от «Руссинович и Ко»

Я честно говоря не думаю что когда речь идёт об обмене сообщениями между компонентами ядра то подразумевают системные вызовы. Выше я кидал ссылку на источник, там сказано - «Эти компоненты взаимодействуют между собой с помощью межмодульной связи. Каждая компонента вызывает другие с помощью набора тщательно специфицированных внутренних процедур». То есть это не системные вызовы и не обращение ядра к модулям, а именно взаимодействие модулей между собой, как в микроядерных ОС. Если это так то ядро Linux не может ничего подобного. На хрен это нужно и есть ли от этого какая-то польза - вопрос другой.

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

по твоему unlink(2) не является «тщательно специфицированной процедурой»? Да, она не имеет отношения к ядру, тем более к ядру NT, но для примера вполне подходит ИМХО.

То есть это не системные вызовы и не обращение ядра к модулям, а именно взаимодействие модулей между собой, как в микроядерных ОС.

точнее обращение модулей к ядру, что-бы ядро обратилось к другому модулю. А отличие от микроядра ты можешь увидеть и услышать как только попытаешься посмотреть/послушать фильм одновременно с записью флоппи/CD. Драйверы звука и видео висят в том же кольце, что и драйверы записи флопика и CD, и потому друг другу мешают. Это общеизвестный факт. А если-бы архитектура была-бы действительно микроядерной, то такой проблемы не было-бы (за то были-бы другие, по типу как в линуксе, где невозможен в принципе монопольный захват оборудования. Из за чего в частности и тормозят игрушки)

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

само Linux ядро безусловно не может, но вот разделять время на уровне модулей — может, и разделяет. Польза от этого конечно есть, но хомячку она слабо заметна. К примеру, Linux ядро отлично может раздавать интернет Over9000 юзеров одновременно, но хомячковая венда этого не умеет(возможна умеет серверная, но только благодаря костылям и более мощному железу(ИМХО). Я тут не компетентен)

само Linux ядро безусловно не может, но вот разделять время на уровне модулей — может, и разделяет.

Что-то я не понял о чем ты. Преемтивность ядра есть и там, и там. Причем в nt она появилась первее, хотя сейчас это уже не важно.

С семерочки вроде это убрали

Да должны были ещё в висте убрать, мелькала такая информация. Но я специально открыл последнее издание книги Русиновича, 2013 года, там как раз семёрочка описывается, и написано там - как выполнялась вся графика в режиме ядра так и выполняется. Как на самом деле ХЗ.

Ядро венды нельзя рассматривать отдельно от венды. Ядро Linux можно, да только использовать его отдельно тоже нельзя

Что сказать то хотели? Линукс нельзя использовать отдельно от винды?

http://aiju.de/rant/os/windows
Если подобное творится и в ядре, его трудно считать чем-то хорошим.
В любом случае, ядра Haiku и Plan 9 прогрессивнее ядер linux и windows вместе взятых.

Что-то я не понял о чем ты. Преемтивность ядра есть и там, и там. Причем в nt она появилась первее, хотя сейчас это уже не важно.

ИМХО нет никакой преемтивности ядра. Ни там ни там. И не было никогда, только в обещаниях, которые так и не сбылись. Просто ядер CPU стало больше одного, и они теперь работают быстрее. Потому и ядро ОС «лишилось проблем» с разделением времени внутри себя. Просто проблемы стали незаметными. Ядро Linux изначально хоть как-то могло рулить модулями, планировать их действия, но внутри самого ядра всё так и осталось однозадачным(конечно не всё так примитивно, но в целом всё примерно так и есть).

Переписывать ядро силёнок не у кого не хватает. Вот так и живём — либо на древнем linux'е, либо на ещё более древнем nt. Т.е. ядро-то переписать можно, проблема не в этом, проблема в том, кто будет писать 100500 драйверов под принципиально новое ядро? Да и в чём профит этого мероприятия, если оно работает и так. Плохо, но работает. Если уж надо что-то СЧИТАТЬ, то дешевле сделать ASIC. А если просто фконтактег погонять, то достаточно CPU на $10 дороже. Т.ч. твоя преемтивность так и останется в планах, о которых все давно уже и позабыли.

и написано там - как выполнялась вся графика в режиме ядра так и выполняется. Как на самом деле ХЗ.

AFAIK ядро NT6 является доработанной версией NT4/5. Уж если-бы это было не так, нам-бы маркетологи давно весь мозг проели. Да и ПО то-же бы сломалось, что работает непосредственно с ядром. А такого ПО в маздае каждое второе. Там у них грязные хаки — это норма поведения. Это же только в Linux если API кривое, то ломают API и делают новое. В венде API со времён NT4. И если оно кривое, быдлокодеры его обходят. А все эти обходные хаки сильно завязаны на архитектуру самого ядра.

ИМХО нет никакой преемтивности ядра.

Есть

но внутри самого ядра всё так и осталось однозадачным

Нет. Ты хотя бы про обработку прерываний и о потоках ядра почитал

В венде API со времён NT4. И если оно кривое, быдлокодеры его обходят. А все эти обходные хаки сильно завязаны на архитектуру самого ядра.

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

Ядро венды нельзя рассматривать отдельно от венды. Ядро Linux можно, да только использовать его отдельно тоже нельзя

Что сказать то хотели?

некорректно сравнивать ядра вне окружения. Просто не имеет никакого смысла такое сравнение. И в окружении тоже не корректно. Ядро маздая не работает с glibc, и обратное верно. Сравнивать можно только конкретный дистрибутив с конкретной сборкой венды, но тут сами понимаете — всё зависит от радиуса кривизны рук сборщика сборки. От ядра мало что зависит. А радиус кривизны рук зависит от доступности документации всех уровней, и потому Linux получается при прочих равных лучше. Если конечно сборщик маны читает.

Если подобное творится и в ядре, его трудно считать чем-то хорошим.

всё ЕЩЁ хуже. Если для WinAPI верно

Documentation sucks, it's often ambiguous and sometimes outright wrong. Since there is no source, you're basically fucked in that case.

то для ядра ОС документации ПРОСТО НЕТ. Максимум что можно найти: либо реверс, либо смотреть утёкшие старые исходники, надеясь что ничего не изменилось(а хрен там, ибо число костылей завораживает)

Что особенно хреново, так это то, что костыли обычно костылят не правильно, явно для того, что-бы по быстрому залатать. Костыль надо костылить СНАРУЖИ, А НЕ ВНУТРИ. Это бл очевидная же ортопедия! Но костылят внутри. Потому даже если ногу вылечат, ты так и будешь греметь этим костылём до скончания века. Иначе ходить ты не сможешь, костыль вживлён, и без него ты умрёшь. Это всё нереально IRL, но для индусов так проще. Галка «поддерживается» же есть!

В любом случае, ядра Haiku и Plan 9 прогрессивнее ядер linux и windows вместе взятых.

ну возьми любой компьютер, и поставь туда plan9. И к гадалке не ходи, что 95% оборудования работать не будет.

Нет. Ты хотя бы про обработку прерываний и о потоках ядра почитал

та я читал. Я же признаю, не всё так примитивно конечно, но тебе стоит напомнить о том, что прерывания они и в MS-DOS вообще-то были. И «многозадачность» была.

Как я слышал особенно эти дыры и костыли портят нервы разработчикам wine и всяких ReactOS, они то вынуждены воспроизводить их для совместимости. Может это и анекдот, но похоже на правду.

какой нафиг «анекдот»??? Программа написанная полностью по MSDN(без хаков) отлично работает в Wine, с первой версии вина(если не раньше).

Там проблема даже не в самих хаках, а в том, что маздайщики их находят самостоятельно, методом тыка. Потому этих хаков Over9000000. Их все в wine принципиально невозможно засунуть, туда засовывают только лишь известные «фичи». А если уж надо какую-то программу кровь из носа запустить, то приходится делать специальный форк wine, вроде исконно русского wine@elcomsoft, сам знаешь для чего. Ибо вводить Over900000й костыль в главную ветку из-за одной программы решительно нереально.

На моём компьютере там не работает только встроенный ethernet. (inb4: аппаратное ускорение, план его просто не умеет) Работает даже звук там.
Но да, проблема с драйверами есть у любой немейнстримовой ОС.
Основная проблема в том, что софт там мало изменился с 90-х годов, и очень много чего придётся переделать, чтобы получить юзабельную систему.

В любом случае, ядра Haiku и Plan 9 прогрессивнее ядер linux и windows вместе взятых.

Вы пытаетесь привнести элемент юмора в нашу дискуссию? «Прогрессивное» и «никому не нужное» - это далеко не всегда синонимы ))

В любом случае, ядра Haiku и Plan 9 прогрессивнее ядер linux и windows вместе взятых.

ну возьми любой компьютер, и поставь туда plan9. И к гадалке не ходи, что 95% оборудования работать не будет.

А почему «поддержка железа» и «прогрессивность» у Вас приравнены?

А можно пруф? Бенчмарки типичных задач поверх haiku/p9 и поверх линуксов/венды для сравнения, например.

Красота на бумаге хороша разве что для диплома.

Бенчмарки типичных задач поверх haiku/p9 и поверх линуксов/венды для сравнения, например.

«Преждевременная оптимизация - это корень всех бед» (C)

Но да, проблема с драйверами есть у любой немейнстримовой ОС. Основная проблема в том, что софт там мало изменился с 90-х годов, и очень много чего придётся переделать, чтобы получить юзабельную систему.

ты немного не понял, что значит «работа с оборудованием»(в моём понимании). Если это например флешка, она должна сама определиться, и сама смонтироваться если мне так хочется. Т.е. поддержка оборудования должна быть не «голая», а на уровне программ тоже. А я так щитаю, что в план9 это как в Slackware Linux с f2fs — ежели покрасноглазить, ежели собрать initrd, ежели найти/написать слакобилд, то заработает. Но без fsck. Fsck вроде кагбэ уже есть на сегодня, но ещё недоделана (а в стабильной версии вообще нет(только mkfs), юзаю бету на свой страх и риск, с гитхаба сырцы стянул и сам собрал). Т.е. если честно признаться, то не готово ещё. Хотя и УМВР.

ну возьми любой компьютер, и поставь туда plan9. И к гадалке не ходи, что 95% оборудования работать не будет.

А почему «поддержка железа» и «прогрессивность» у Вас приравнены?

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

А почему «поддержка железа» и «прогрессивность» у Вас приравнены?

Дык они не приравнены - просто сложно называть дизайн программы о**енным, если программа не работает. А классические опенсорсные обещания «подождите еще 100 лет, мы всё допишем и тогда порвем вас как тузик грелку» на бутерброд не намажешь.

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

Черт, опоздал.

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

Затем, что это ствол. А веточки потом будут. А без ствола их не будет в любом случае.

А можно пруф? Бенчмарки типичных задач поверх haiku/p9 и поверх линуксов/венды для сравнения, например.

нельзя. Первые самобеглые тележки были куда хуже кареты. К тому-же, на сегодня ещё не очень понятно, является-ли этот микроядерный подход лучшим. Тесла вот тоже пытался электроэнергию по воздуху передавать — не получилось. И AI ещё 30 лет назад планировали сделать — не сделали. Я уж молчу про intel, с её бескостыльной и прогрессивной IA-64. Так до сих пор и костыляем i8086, которому лет как мне почти.

Затем, что это ствол. А веточки потом будут. А без ствола их не будет в любом случае.

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

Дык они не приравнены - просто сложно называть дизайн программы о**енным, если программа не работает.

Вы же явно знаете, что и haiku, и plan9 работают. Да, они не в mainstream'е. Но это же не означает, что их вообще невозможно запустить или что они практически непрерывно падают.

Немножко передергивания и готово громкое «программа не работает».

не факт, что и со стволом будет

Совершенно согласен.

Но здесь, как в математике: «необходимое, но не достаточное».

На моём компьютере там не работает только встроенный ethernet.

VT-x работает? VT-d?

Но здесь, как в математике: «необходимое, но не достаточное».

что-бы оно было достаточным, нужно что-бы профит был-бы _значительно_ больше. Причём учитывая _все_ накладные расходы. Фанатеги не понимают простой вещи: профит есть, но есть и расходы. Например написание драйверов для микроядер и самих микроядер намного дороже. Также и то, что это микро ядро получится IRL больше размером, и будет жрать больше памяти, при том же функционале. Да и работать медленнее. И особенно всё будет плохо, если основная задача одна. А именно такой случай мы и имеем в десктопах, лаптопах, и на рабочих станциях. С серверами сложнее, но часто и там микроядерность не нужна, достаточно кормить Over9000 приложений равным количеством тактов. IRL остаётся лишь случай, когда надо форматировать дискетку и _одновременно_ играть в видеоигру со звуком. Ну или играть в линуксе, где никто не даст игрушке самой разруливать звук/видео/AI с физикой. Этим будет заниматься само ядро, а оно не очень в курсе текущих приоритетов. Потому работать это всё будет красиво и реалистично лишь при хорошем запасе железной мощности. Если запаса нет, ядро может не вовремя отвлечься на задачу, которая вот в эту миллисекунду не очень и нужна. А всё остальное будет ждать, ибо ядро-то одно. И приоритетами это не решаемо, ибо их нужно менять чуть-ли не для каждого события.

VT-x работает? VT-d?

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

Например написание драйверов для микроядер и самих микроядер намного дороже.

Также и то, что это микро ядро получится IRL больше размером, и будет жрать больше памяти, при том же функционале.

если основная задача одна. А именно такой случай мы и имеем <...> на рабочих станциях.

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

Этим будет заниматься само ядро, а оно не очень в курсе текущих приоритетов.

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

:)

Похоже, Вы вообще не в теме.

Поток бреда^W эмоций реальные знания не заменит.

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

Однозначно не пригодится. Ведь «на рабочих станциях только одна основная задача».

Кстати, а какая именно?

Похоже, Вы вообще не в теме.

я не очень-то и скрываю сей прискорбный факт. И не спешу исправлять. Причина проста: нет этих ваших архитектур, и не факт, что они вообще появятся.

Однозначно не пригодится. Ведь «на рабочих станциях только одна основная задача».

типа сарказм? Ну сними статистику, раз не веришь.

Кстати, а какая именно?

обычно никакая.

Plan 9, вообще говоря, не микроядро. Ну, если точнее, его ядро — нечто вроде «монолитного микроядка»: есть общий IPC и в теории можно всё делать в пространстве пользователя, но на практике множество вещей реализуются в ядре, чтобы не делать переключение контекста на каждый чих. Но и с ядром взаимодействие идёт через файлы, а не через пару сотен различных системных вызовов.
Главная выгода — простота. Множество вещей, которые в юниксах делают через костыли, в Plan 9 делаются просто.

нет этих ваших архитектур

??

о чем это?

типа сарказм? Ну сними статистику, раз не веришь.

А можно я ничего снимать не буду? Так как очень хорошо помню, какие задачи запускаю у себя на рабочей станции в течение дня.

обычно никакая.

Аргументы все закончились, эмоции сдулись, батарейки разрядились?