OSDev

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

А это реально? Я очень сильно в этом сомневаюсь. Уж очень много завязок на функции ОС. Я, вон, пока что не могу утрясти стандарт даже на гораздо более простую вещь - начальную загрузку. Хотя уже близок к победе.


Бинарного стандарта для *nix нет.

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

Ну давайте и разберем, что тут конкретно нереального. Конечно конкретное ядро может не дотягивать до требуемого функционала, но всегда можно вставить заглушки. Добавить соответствующий функционал все же проще, чем писать все с нуля. Даже для того, чтобы банально заработала USB мышь (можно конечно на BIOS с его SMM эмуляцией PS/2 надеяться, но она присутствует далеко не везде) из под PM на всех современных ПК нужно писать драйвер UHC, OHC, EHC, хабов и непосредственно HID, так вот данная задача потребует времени куда поболее и еще при условии, что есть доступ ко всему железу, желательно для отладки еще разных производителей.

Драйверная модель в очень значительной степени определяет внутреннюю архитектуру всей системы в целом, и наоборот, общие архитектурные решения, принятые при проектировании системы, прямо влияют на драйверную модель. Так, самый лучший и надёжный путь для обеспечения своей системы полным набором драйверов под любое железо -- это использовать драйверы для современных версий Windows. Но на практике это будет означать, что нужно написать не какую-то абстрактную систему собственного изобретения, а именно Windows, пускай и с отличиями в некоторых деталях реализации, ведь рассчитанные на Винду драйверы используют сотни подпрограмм ядра, "закладываются" на определённые правила внутриядерной синхронизации, вполне определённым образом обрабатывают прерывания и т.д. Причём не удастся реализовать 10% системы и надеяться, что даже минимальный набор драйверов заработает -- какие-то, может, и пойдут, но большая часть -- нет, и тупыми заглушками для функций тут не обойтись. Думается, тут придётся реализовать как минимум половину системы, прежде чем всё это дело начнёт работать -- причём делать придётся не только ядро, но и многие компоненты пользовательского режима, ведь далеко не всё выполняется внутри ядра. Вот рабочий стол можно будет не делать -- драйверам он точно ни к чему, но и сложность этого компонента системы по сравнению со всем остальным просто ничтожна.

Драйвера нужны не только для UHC, OHC, EHC, хабов и непосредственно HID, а ещё для разных модификаций сетевух (в сетевухе вприеципи только включается бит активации и подготавливается буфер), для дисков AHCI и HDA драйвер вообще 1.
Я в теме программирования оборудования начинал темы с AHCI и HDA и EHCI сетевухи давал инфу и готовые алгоритмы, но там тишина, даже небыло ответов типо "Привет как дела", так что суди сам.
А вообще тебе shm, с твоими знаниями и кучей собственных драйверов зачем всё это, ты нового ничего не узнаешь здесь, обсуждать программирование контроллеров можно, но ни кто не будет.
Готовые драйвера у меня точно не запустятся, у меня система вызовов своя, через прерывания выходишь в 0е кольцо, а там свои требования к системе, да и прерывания процессов у меня происходят по моим законом "Долгосрочной, краткосрочной спячки объектов", т.к. объекты двух видов дочерние и параллельные(со своим стеком и выполняются параллельно и любым из процессоров). А при прерывании сохраняется адрес возврата в стек прерваного объекта(эта тема аппоратная).

Если желающие найдутся ковыряться в устройствах, то через форумы они всёровно на тебя выдут.

Кстати помимо дров есть интересные темы как форматы, протоколы сетевые, системы файловые.

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

Идея конечно интересная.
Вот только как её реализовать? Система обработки прерываний у меня своя. Менеджер памяти свой и пока в нем разделяемая память непридусматривается. Драйвер диска в планах взять из линукса. Видео драйвер мечтаю о своем. С usb не знаю что делать.

Идея правильная, но не реализуемая. Есть много бинарных дров для Win, есть в сорцах для bsd и Linux - проще пытатся делать универсальный интерфейс к ним чем изобретать собственный велосипед да ещё и универсальный для всех. Вот по отношении к существующим драйверам как-раз можно как-то пытатся соединять усилия - в выработке единого интерфейса и кода к драйверам а потом каждый самостоятельно напишет интерфейсную часть к себе. Есть насколько подобных проектов (для L4-Linux и очень старый для Mach-Linux1X). Если двигатся в этом направлении - имеет смысл поискать по этим проектам материалы и отталкиватся от них.

Да, это видится малореалистичным, даже чисто по объективным причинам (про субъективные типа умения договариваться я уже молчу). Может, лучше начать с изучения существующих драйверных моделей и прямо по пунктам перечислить все условия запуска и нормальной работы любого драйвера в конкретной системе. Потом посмотрим на объем полученных пунктов. Пообщаемся на предмет исключения/упрощения отдельных пунктов без потери гибкости, выявления общих пунктов и обобщения похожих в разных моделях, добавления чего-то нового, способствующего повышению универсальности применительно к разным системам. Если покажется возможным все это реализовать, можно и попробовать. Я ради хорошей и универсальной драйверной модели могу даже пожертвовать своей. Конечно объем переделки будет громадный, но при удачном развитии этой темы дивиденды будут не малые. Я с ACPI и USB бьюсь уже сто лет! Может, найдутся специалисты, у которых эти технологии проработаны хорошо, а не достает только универсальной модели, из-за чего результаты их работы другим недоступны.

По моим наблюдениям, чтобы какая-то техническая идея могла быть воплощена, недостаточно просто бросить клич, навалиться толпой и что-то сделать. Обычно получается картина "Лебедь, рак и щука", если вообще что-то получается. Для успешной реализации нужен "паровоз", т.е. некоторый лидер проекта, который заведомо обладал бы:
1. богатыми знаниями и опытом в соответствующей области;
2. достаточную мотивацию для поддержания проекта;
3. технические возможности по её реализации.
Вот мы, например, имеем опыт разработки драйверов под Windows для наших устройств и по опыту могу сказать, что даже помимо особенностей архитектуры ОС каждая железка обладает какими-то уникальными особенностями, которые сложно учесть в общей драйверной модели. Например, разработали модель устройств ввода/вывода. Оказалось, что видеодрайвер (будучи устройством вывода) должен поддерживать огромную кучу специфических явлений, таких, как 2D/3D-ускорение. Хорошо, разработали трёхмерную модель. Вслед за этим оказалось, что есть устройства видеоввода, такие как веб-камеры и ТВ-тюнеры, которые работают на совершенно других принципах. Хорошо, поддержали видеоввод. Затем оказалось, что видеокарты имеют специальное ускорение для устройств видеоввода, например, оверлей со своими цветовыми настройками, поддержкой цветового пространства YUV, деинтерлейсингом (уже страшные слова, да? А ведь это стандартные функции любой современной видюшки). Ладно, поработали пару лет, договорились. Потом выясняется, что есть вообще странные железки, например, трёхмерный ускоритель 3Dfx Voodoo или ТВ-тюнер Tekram M200, которые картинку накладывают не через видеопамять, а через видеокабель, подмешивая и заменяя непосредственно видеосигнал. А есть такие чудеса природы как аппаратный видеодекодер MPEG (PCI плата!) или аппаратный ускоритель общего назначения на транспьютерах Inmos T800. А сейчас уже и видюшки выступают в роли аппаратных ускорителей (GPGPU). И для каждого такого направления нужен свой "паровоз". И как всё это учесть? "Есть ли у вас план, мистер Фикс?" (с)

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