Цитата:
Согласитесь, что плохонаписанный драйвер находящийся за пределами ядра это лучше чем плохонаписанный драйвер, который является частью этого ядра?
Не соглашусь. Мне как пользователю абсолютно плевать, потерял я данные в результате падения всей системы из-за кривого драйвера режима ядра или же потерял те же данные из-за падения драйвера режима пользователя. Плохо написанных драйверов, как и вообще модулей ОС, быть попросту не должно.
Цитата:
Я и не говорю что без последствий, я просто пытаюсь до вас донести мысль о том что эти последствия можно и необходимо минимизировать. Или накроется часть системы и полетит часть данных или накроется полностью вся система, что лучше?
Сбои в критически важных драйверах будут фатальными для всей системы независимо от того, внутриядерные они или нет. Например, если сбойнул драйвер ACPI, рухнет вся система, поскольку через него идёт раздача ценных указаний, касающихся управления электропитанием и конфигурированием многих устройств. Если рухнет драйвер PCI Express, то опять-таки рухнет вся система, поскольку будет потеряна возможность управлять конфигурированием и электропитанием устройств на этой шине. Причём корректный перезапуск подобных драйверов, вообще говоря, невозможен, поскольку неизвестно состояние, в каком находятся управляемые ими устройства, и не всегда имеется возможность его получить заново (ну а области данных упавшего драйвера с изрядной долей вероятности будут запороты). Поэтому надо бороться не с "минимизацией последствий", а с отсутствием ошибок в критически важных компонентах системы -- но тогда нет и смысла их отделять друг от друга. Вот второстепенные драйверы, при сбое в которых корректное восстановление системы возможно, имеет смысл выносить в отдельные процессы -- но в Висле и Семёрке так и сделано, что не делает их микроядерными системами, это по-прежнему монолиты (ведь все основные функции сосредоточены в одном общем адресном пространстве ядра, да и вынесенные наружу драйверы при желании можно внести в ядро).
Цитата:
Ядро Windows NT изначально было микроядро, но из-за низкой скорости работы системы(переключение контекстов частое) перешли на модульное ядро.
С чего Вы взяли, что NT была микроядерной системой? Она всю жизнь была монолитом. Ну а то, что графическая подсистема изначально была реализована не в ядре, не делает всю ОС микроядерной: всё остальное, включая драйверы, находилось в ядре. Потом да -- перенесли изрядную часть графики в ядро, чтобы уменьшить количество переключений контекстов, но это лишь сделало монолитное ядро более жирным, а не превратило микроядро в монолитное.
Цитата:
Вся соль в том чтобы вынести из нулевого кольца процессора неблагонадежный код, а оставить там только выверенный минималистичный код, который обеспечит работу компьютера в самом минималистичном режиме.
Кода, совершенно необходимого для работы сколько-нибудь полноценной ОС, весьма и весьма много, и почти весь он должен быть благонадёжным, иначе система работать всё равно не будет (постоянные падения вынесенного из ядра драйвера столь же неприемлемы, как и падения всей системы: всё равно работать невозможно). Поэтому-то микроядра, так хорошо выглядящие в плане надёжности на бумаге, на практике почти не встречаются (даже QNX можно назвать микроядерной лишь с известной натяжкой, ведь почти все системные сервисы там лежат в ядре).
Цитата:
Вот мы плавно подошли еще к одному очень важному приемуществу экзоядра - его минималистичности. Что она нам дает кроме сравнительно легкого его переписывания при портировании на другие платформы, а дает оно нам то что оно будет полностью помещаться в кэш процессора, а это огромное преимущество которое трудно переоценить.
По экзоядру я прокатился в своём предыдущем посте, но дело, конечно, не в этом, а в том, что заставить процессор удерживать в кэше что-то определённое не так-то просто, да и не требуется: в кэше должно лежать то, что используется чаще всего, а это вовсе не обязательно ядро в полном составе, даже очень маленькое. Например, тому самому экзоядру из статьи на Вике делать в кэше попросту нечего: реализованные в нём сервисы вызываются сравнительно редко, и почти всё время выполняется либо код приложений, либо код libOS. Так что способность впихнуть всё ядро в кэш -- это не аргумент.
Цитата:
Из двух зол выбирают меньшее, из гибкости и стабильности я выбираю стабильность. Гибкость должна быть не в ущерб стабильности.
Я уже говорил и повторяю снова: есть компоненты, которые невозможно качественно перезапустить в случае сбоя, т.е. они должны работать без всяких сбоев. И выносить такие компоненты за пределы ядра нет никакого практического смысла. Посему архитектура, допускающая расположение драйверов и в ядре, и вне ядра, является наилучшей.
Цитата:
Я это в курсе, это не проблема ОС, это проблема самой архитектуры x86 на железном уровне(честно не знаю как обстоят дела в других архитектурах по этому поводу), но мы же говорим про ОС не именно под x86, а про мультиархитектурную ОС. Если говорить именно про архитетктуру x86, то я думаю софтово можно если не обойти, то хотя бы минимизировать этот недостаток.
Вот сначала придумайте, а потом говорите. Ну а заодно поизучайте другие архитектуры -- очень полезно. Конечно, архитектура ИА-32 -- жутко кривая, но абсолютно во всех архитектурах ввод-вывод связан либо с доступом к регистрам устройств, либо с выполнением специальных команд ввода-вывода, либо с тем и другим, ну а плюс -- с обработкой прерываний, а посему проблемы остаются те же самые: нередко невозможно обеспечить надёжную защиту драйверов друг от друга (т.е. сделать так, чтобы один драйвер никакими ухищрениями не мог нанести ущерб другому драйверу -- залезть в чужую память или там обратиться к чужому устройству), ну а в тех случаях, когда это технически осуществимо, это приводит к существенному падению производительности.
Цитата:
Опять же это недостаток x86, а не ОС на экзоядре
Снова повторяю: сначала изучите другие архитектуры, а потом говорите. Операция переключения контекста -- очень медленная на любой архитектуре, и чем выше производительность процессора, тем больший ущерб она наносит.
Цитата:
Могу сказать что экзоядро уже работает и его пока изучают в американском по моему массачусетском университете
Британские учёные тоже много чего изучают -- но на практике почему-то используются в основном монолиты или же не совсем полноценные микроядра (вроде QNX).
Цитата:
Почитайте пожалуйста чем занимается экзоядро - оно выполняет минимум функций необходимых для того чтобы работал процессор и оперативная память, а остальное все экзоядро отдает на откуп сторонним программам(экспортирует на непривилегированный уровень)
Извините, но тут Вы сказали полный бред. Процессор и оперативная память работают без всякого ядра вообще; максимум, что им нужно, да и то не во всех архитектурах, -- это предварительная настройка кой-каких "железных" параметров, чем ядра систем не занимаются в принципе (в ПК все необходимые настройки процессора и чипсета выполняет BIOS).
Цитата:
Скажите мне, при трансляции(компиляции) явамашина оптимизирует получившийся код под конкретную платформу, она знает все ее закоулки? Вообще здесь накладывается 2 тормоза друг на друга, это ОС и виртуальная машина, - получается слишком длинная цепочка до аппаратного обеспечения, я за то чтобы ее сократить, вы за или против?
Насчёт "знает" -- не знаю. Однако именно такой подход теоретически обеспечивает наивысшее качество кода под любую платформу. При классической компиляции исходный текст программы компилируется в машинный код один раз, поэтому он может быть наилучшим образом оптимизирован лишь под одну платформу. Например, если требуется, чтобы некая программа работала на любых 64-разрядных процессорах архитектуры ИА-32, она в принципе не может использовать инструкции SSE4 и более поздние (а возможно, и не все SSE3, тут уж не помню) -- а соответственно, она может оказаться не самой эффективной для более новых процессоров. В то же время динамический компилятор вроде Жабы способен компилировать именно под тот процессор, на котором код реально будет сейчас выполняться, а значит, сделать это эффективнее.
Наконец, что касается "двух тормозов", то это тоже бред. Возьмите классическую программу на языке высокого уровня: для выполнения файлового ввода-вывода она вызывает библиотечные функции, а уже они -- соответствующие функции API. Если же для ввода-вывода используются потоки, то дело ещё хуже, поскольку потоковый ввод-вывод реализован с помощью классов, а ООП, как известно, производительности не способствует (хотя при грамотном использовании не слишком её убивает, но даёт взамен ряд преимуществ). Так что, исходя из Вашей логики, тут тоже два тормоза: сначала RTL, а затем -- ОС. Так почему RTL в виде виртуальной машины должна непременно быть хуже, чем классическая RTL?
Цитата:
Я это прекрасно понимаю, я знаю что все сложнее, но это уже детали разработки протокола и это все выполнимо. Насчет "просто дизайнера", это в любом случае будет не просто дизайнер, в любом случае человеку придется осваивать инструментарий разработки GUI где нужно будет писать/составлять алгоритмы работы GUI, но это будет не сложнее чем работа с GUI в Delphi, я так себе это представляю
Вот не представляйте, а сделайте. Или хотя бы тщательно спроектируйте, чтобы в деталях было видно, как всё это должно работать.
Цитата:
Объясните мне разницу в выходящей информации от драйвера клавиатуры(реальной, ирутальной) и от драйвера рукописной системы ввода? И там и там передаются символы
Во-первых, гуй не сводится к обработке нажатий на клавиши. А во-вторых, у реальной клавиатуры, помимо алфавитно-цифровых, есть ещё куча других клавиш -- например, переключение регистров, стрелки, табуляция, функциональные и т.п. В случае системы рукописного ввода придётся каким-то образом придумывать им замену.