То 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 и других. Но с ними еще нужна функция синхронизации так как ЦП и ГП аботаю параллельно. Естественно все это опционально, т. е. к примеру возможна модель, когда драйвер возвращает структуру где описывает некоторые характеристики, а также указатели на соответствующие функции. Если указатель нулевой, то драйвер/устройство эту функцию не поддерживает и соответственно ОС должна уметь ее эмулировать. Это сугубо мое мнение.
|