OSDev

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


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


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

Да, Колибри слабенькая по многим направлениям. Советчикам отвечают агрессивно, в лучшем случае просят присоединиться и допилить самому.

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

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

PS: по вашему вопросу в ЛС мне нечего сказать.

Ну вот насчет необходимости переключений я бы поспорил. Если реализовать механизм обработки клавиатуры в виде библиотеки, которая будет работать в адресном пространстве задачи которой это нужно, наверное никуда и переключаться не надо. Самому ядру клавиатура далеко без разницы, так как в любом случае с пользователем общается оболочка, которая запускается как отдельный процесс, и вот как раз ей оно надо. Да, хорошо. Все начитались умных книжек, в которых описывается одна (максимум две) широкоизвестные ОС, и начать думать с нуля, придумать свои структуры для обработки необходимых процедур и данных конечно кажется трудным. Или просто не хочется. Зачем, если уже придумали и вроде как все просто прекрасненько у них там работает. Кому нравится виндовоз, так и пусть на нем сидит. И концепции MS and Linux, просто восхищают. Особенно политика увеличения емкости памяти под все их художества... Растет объем кода, а не его функциональность. Портируемость вещь хорошая, только вот оно надо рядовому пользователю? У кого дома под столом стоят АРМ, ну или другие какие платформы? Еще раз повторюсь, писать еще одну похожую на другие операционку - в чем смысл? А если считается что непохожа, так приведите что вы сами в ней сделали, какая концепция именно вами разработана, а не вычитана у других. Или даже пусть вычитана, но реализована каким-нибудь нестандартным подходом. Тогда еще вижу смысл диалога. А так это типа мальчик хвастается перед девочкой - ой смотри какая штучка у меня есть... Так у всех она есть
И прежде чем меня обвинять в том что я не разбираюсь, хотелось бы узнать ответы на вышеприведенные вопросы, чтобы не спорить с человеком который в своей жизни ничего не создал реального.

Прежде чем Вы начнете обрабатывать клавиатурный ввод - надо чтобы ядро "поймало" прерывание и дальше "дергало" соответствующий драйвер. Драйвер может быть и в юзерспейсе. Если разрешить ловить прерывания кому угодно (весь код в привелегированном режиме) то это будет не система а решето.

"Кто хочет научиться летать, тот должен сперва научиться стоять, и ходить" (С) Ф.Ницше. Очень Вам советую прежде чем строить собственные концепции, посмотреть как и что сделано в существующих системах. Отпадут многие вопросы и предположения. Возьмите тот-же миникс например - к нему есть отличная "объяснялка" по всему коду.

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


Не знаю, как Вы, а я работал системным программистом (а не читал) с RSX-11, OS/360, VM/370 и немного VAX/VMS -- ну, не считая Windows NT.


Функциональность тоже растёт; правда, куда больше всяких свистоперделок появляется, чем чего-то полезного. И, кстати говоря, концепции и рост объёма кода -- вещи вообще никак не связанные. Грубо говоря, даже прекрасная концепция, реализованная плохо, будет работать плохо, и наоборот (по крайней мере, с точки зрения пользователя, который не видит, что делается "под капотом").


У меня, а что? И мэйнфрейм стоял бы, если б я был миллионером. Да и пишу систему как раз под АРМы (и даже использую в коммерческом продукте).


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


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

Ну, собственно, это и есть причина, почему концепция экзоядра неработоспособна в принципе: она не позволяет создать систему, которая не "падает" от ошибок в программах пользователя. Дело там, конечно, не только в вводе-выводе, но он очень хорошо иллюстрирует проблему.


Не знаю насчёт Миникса -- Танненбаума не читал, да и вообще, любая ОС, произошедшая от Униха, является больше примером того, как не надо делать ОС, -- но почитать/разобраться стоило б даже с посредственной системой. Просто не надо любое изученное решение возводить в абсолют и считать, что сие есть идеал.

Насколько мне известно из документации по Intel, прерывания обрабатывает IDT (там содержится адрес где искать обработчик). Flat модель подразумевает использование 1 сегмент кода и 1 сегмент данных для ядра, плюс 1 сегмент кода и 1 сегмент данных под все остальное (разбитое на страницы). Я не прав? Переключение контекста - как раз таки межсегментный переход из сегмента "все остальное" в сегмент ядра. И зачем это делать обработчику клавиатуры - ну никак понять не могу.
Падение от ошибок пользователя - неправильная обработка исключений. Если подойти к каждой ошибке рационально и падений не будет. Тот же миникс у меня в вируалке не падал, хотя я ему подсовывал корявые программки, просто для проверки. Хотя разок упал, только вместе с виртуалкой. Тут надо еще было бы понять что именно упало - виртуалка или миникс.
О да, я тоже на промышленном контроллере ЭМИКОН пописал программы, управление установкой. Там как раз и обработчик клавиатуры нужен (как собаке пятая нога), и конечно же юзерспейс, и рабочий стол графический. Насмешило. Пугать этим школьников - однозначно.

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


Частично правы. Сегменты в таком контексте -- вещь, встречающаяся крайне редко (в первом приближении можно считать, что только в IA-32). А правы не полностью, а частично по той причине, что никакого разбиения на страницы плоская модель не предусматривает: включать страничный механизм вовсе не обязательно. Плоская модель противопоставляется сегментированной, а отнюдь не означает автоматически, что будет использоваться виртуальная память на основе страниц. Более того, в системах жёсткого реального времени использовать MMU не всегда допустимо вообще -- из-за того, что этим вносится дополнительная неопределённость в плане времени реакции системы и т.д. и т.п.


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


Потому что совершенно не понимаете, как работает процессор.

1. При возникновении прерывания в процессорах архитектуры IA-32 всегда выполняется межсегментный переход -- хотите Вы этого или нет. Другого способа в обработчик прерываний попросту не существует что в реальном режиме, что в защищённом. Лишь в 64-разрядном режиме переход не межсегментный -- но только потому, что там сегменты упразднены.

2. Для выполнения сколько-нибудь сложной последовательности действий программе, написанной под IA-32 (да, по большому счёту, для любого процессора) требуется использовать некоторое количество регистров. Однако после возврата из прерывания их содержимое должно остаться тем же, что было на момент прерывания -- иначе прерванная программа не сможет продолжать корректное выполнение. А значит, для обработки прерывания необходимо сохранить контекст текущего выполняемого потока (или кода ядра системы, если прерван был ядерный код), а после завершения обработки -- восстановить его.

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

В общем, матчасть учите. А заодно и русский подтянуть не помешает.

Ппц. НичЁ что такое описание подходит только одному процессу, а не всей совокупности процессов. Как SII сказал, под переключением контекста без каких-либо доп. уточнений понимается переключение потоков и даже процессов. Переключение процессов – одна из самых затратных по времени операций, и здесь даже не столько дело в объеме выполняемого при этом кода. Во всяких недоядрах прерывание в лучшем случае обрабатывается по схеме «текущий-ядро-сервер-ядро-клиент» (а часто еще требуется подтверждение серверу от клиента). Всякие утопичные схемы, когда ядро полностью устраняется от начальной обработки прерываний, оставьте при себе. В таких схемах просто-напросто функции ядра берут на себя другие сущности, при этом многократно дублируя весь функционал и вызывая массу несостыковок. В монолите часто бывает, что при обработке прерываний вообще не происходит переключения контекста (когда все ждут, часто именно текущему процессу предназначается первое возникшее прерывание). В более сложном случае: текущий-ядро-клиент.

ИМХО тему в топку. Всезнающий и мудрейший Demonikss ее засрал своими умоизречениями. устроить холивар из простого вопроса нужно уметь. судя по Вашим постам, ув. Demonikss, вы из ряда тех, кто ничего не написал и написать не может из-за того, что "это уже есть".