OSDev

То SII.
Взять тот же Линь, им приспичило и сделали NDISwrapper, хотя архитектура абсолютно различная. Драйвер, независимо от архитектуры ядра под которое он написан, должен обеспечивать поддержку функционала конкретного девайса и творчество тут не к месту, поэтому и особого стимула писать именно свой драйвер я не вижу в отличие от того же загрузчика. Вот мой личный пример, хотя и не совсем касаемо драйверов. Я проектировал функционала ядра своей ОС большей частью по подобию WinApi (но не клон), по крайней мере в той части, где у меня не было своих идей. Как то познакомился ОС Колибри, посмотрел ихние сис. вызовы и реализовал поддержку (по большей части в виде конвертеров вызовов), буквально после двух недель работы у меня заработала половина их приложений. Но потом правда пыл мой охладел, когда я вник в их убогую дисковую архитектуру и еще в некоторые вещи, реализация которых мне мягко говоря показалась странной.

То Станислав.
При всем уважении к тебе и к твоей ОС, я хочу заметить, что реально то, что мы (я, ты и многие тут) делаем, а именно реализация драйверов устройств PC - это объективно убогие поделки. Реально я не видел в подобных проектах ни одного более-менее законченного решения. Я уверен, что со временем к тебе придет осознание данного факта, по себе знаю. И это физически не реально одному человеку, вот собственно отсюда и идея этой темы. И для фС тоже пишутся драйверы.

То Pavia.
Что конкретно особенного в твоей обработке прерываний, что коренным образом отличает ее от существующих реализаций?
Про прерываниям на мой взгляд достаточно лишь в минимальном варианте согласовать следующий функционал: установки обработчика на конкретный IRQ, подать сигнал EOI и разрешить/заблокировать сигнал по конкретной линии.

То D-S.
Идея правильная, но боюсь, что не потянем. В любом случае, если остальные будут "за", то я не против попробовать.

То phantom-84.
Я полностью согласен с твоим мнением. Я считаю, что архитектуру конкретного класса драйверов должны заниматься люди, уже "плотно" поработавшими с этими типами устройствами. Я, к примеру, со своей стороны могу разработать некий стандарт на USB. Также в качестве рецензии в последействии хотел бы выслушать мнение и доработки других людей, корыте имели с эти дело: Иван, Стас (если захочет присоединиться) и других. В последствии, если все получится, то готов предоставить свои реализации этого и многого другого. Но это ближе к выходным, когда времени будет больше для полета мыслей. Конечно до USB нужно определиться с фундаментальной абстракцией устройства как такового и шинами. Ну, думаю, по поводу того же PCI все будут готовы предложить свои идеи. Вот по поводу ACPI я не возьмусь что-либо стандартизировать т. к. плотно не работал с ним. В тоже время готов согласится с любой разумной моделью.
А прежде всего нужно определиться с еще более фундаментальными вещами (это пока не коим образом не стандарт а изучение общественного мнения).
Что должен представлять из себя драйвер, я это к тому, что у некоторых микроядро. Все ли готовы сделать "послабление" в сторону драйвера как модуля пространства ядра? Если нет, то обсудим отдельно.
Второй момент - это формат исполняемого файла. Я голосуя за PE, но принципиально готов согласится на любой, которые без лишней головной боли поддерживают современные компиляторы, так что предлагаем.
По поводу памяти:
На самом деле, на мой взгляд, многого тут не надо.
(предпологаю, что у всех плоская модель, если я не прав, то нужно обсуждать опять же отдельно)
На вскидку: Нужна функция проецирования участка физического пространства на пространство ядра (это для MMIO). Нужна функция выделения страниц RAM с атрибутами вроде: не кэшируемая, доступна для записи, без фрагментации страниц и др. Так же неплохо бы добавить в функционал функцию выделения памяти из локальной кучи ядра, но не обязательно. Вот в общем то это и есть крайний минимум, который уже сейчас, думаю, есть у всех.
Ну и среди прочего мьютексы само собой.
Более предметно опишу ближе к выходным.

То Yoda.
Не согласен с тем, чтобы кто-то становился лидером, это погубит идею т.к. многие с его мнением будут не согласны. Лучше если каждый будет предлагать свои идеи на основе опыта и в результате голосования и обсуждений можно выработать стандарт.
По поводу видеокарточек:
Имею некоторый опыт работы со старыми Radeon'ами, и вот недавно "поигрался" intel'овскими чипами.
По поводу 3D и аппаратного декодера видеопотока скажу сразу: слишком сложно и у каждого есть куда более приоритетные задачи. Конечно можно взять за основу тот же OGL, но даже если это и будет когда-либо нами частично реализовано, то к моменту выхода более-менее отлаженной версии драйвера для конкретной серии карт, то они уже устареют к этому времени. А совместимости там нет никакой даже в рамках одного производителя. Реализация "на скорую руку" выльется лишь в постоянные артефакты и зависания, которые никому не нужны.
Что тут реально на мой взгляд можно сделать в этом направлении:
Аппаратный курсор (реализуется достаточно просто на всех исследованных мною карточках) : нужна ф-я получения доступных размеров и bpp изображения. Также ответственно функции загрузки изображения курсора, перемещения и управления видимостью. Вот собственно и все.
Можно группу функций установки/получения доступных видеорежимов. (хотя меня лично в этом плане полностью устраивает VESA).
Можно некоторую группу функций 2D ускорения вроде BitBlt и других. Но с ними еще нужна функция синхронизации так как ЦП и ГП аботаю параллельно.
Естественно все это опционально, т. е. к примеру возможна модель, когда драйвер возвращает структуру где описывает некоторые характеристики, а также указатели на соответствующие функции. Если указатель нулевой, то драйвер/устройство эту функцию не поддерживает и соответственно ОС должна уметь ее эмулировать. Это сугубо мое мнение.

Формат файла - это мелочь! Если бы все дело было только в этом, я уже давно поддержал бы все известные мне форматы файлов драйверов. Если народ/отдельные его представители не согласится на распространение исходников, можно распространять в виде объектников. Формат объектников еще меньше важен, т.к. получать из них бинарники можно даже не в родной системе. Кроме того, можно использовать разные форматы объектников.

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

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


PE лицензионно несвободен примерно со следующей формулировкой: Инструменты, генерирующие формат PE, должны создавать только файлы, предназначенные для работы в ОС Windows. То есть, нельзя создавать PE для ОС, отличных от семейства Windows. В связи с этим у меня, кстати, возникают серьёзные возражения, а как же использование PE для UEFI? Ведь для UEFI модулей предписано иметь формат PE, а вместе с тем, эти модули не только могут, но и должны поддерживаться в других ОС. Здесь явно чей-то недосмотр.
ELF лицензионно свободен и его можно использовать в любой ОС.


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


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

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

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

На самом деле это ерунда. Используют все кому не лень. Та же ReactOS, думаю, по мимо PE еще кучу других Пиндосских патентов нарушает и ничего... На самом деле патенты на такие вещи не имеют юридической силы в большинстве стран в т.ч. и России. Второй момент в том, что у каждого патента есть срок действия и вот касательно PE он если еще не истек, то должен в ближайшее время... Но в общем я понял, что ты за ELF, я не против.

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

Что мешает ввести в архитектуру два уровня поддержки драйверов: один для серверов, другой для модулей ядра.

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

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