Board.KolibriOS.org

Предварительный код.
Выполняет сканирование шин ACPI и PCI, определяет диапазоны ввода-вывода и другие необходимые ресурсы. В конце работы выводит таблицу обнаруженных устройств PCI и номера IRQ в PIC и APIC режимах. Устройства не использующие irq в список не попадают. Пример таблицы: Для тестирования диспетчера устройств я создал специальный бранч Kolibri-acpi.
На первом этапе необходимо включить в ядро патч Ghost-a настраивающий APIC. Примерный порядок работы: ядро проверяет наличие ioapic и возможность работы через io_apic, устанавливает переменную apic_mode в ACPI_IRQ_MODEL_IOAPIC=1, затем загружает диспетчер устройств. Диспетчер выполняет инициализацию ACPICA и определение устройств, описанное выше. В конце инициализации в кофигурационное пространство PCI будет записан номер IRQ в режиме IOAPIC. После этого существующие драйверы смогут работать с устройствами без изменения кода.

На втором этапе необходимо убрать из ядра и перенести в диспетчер устройств
- прямой доступ к шине PCI(bus/pci32.inc)
- резервирование портов ввода-вывода
Переписать работу с обработчиками irq
- удалить функции 41 42 44 45
- сделать каскадные обработчики irq
- сделать обработчики irq пользовательского режима.

Заключительный этап. Переход к полноценной драйверной модели.
- к существующим спискам устройств acpi и pci добавляются списки логических устройств и драйверов/сервисов. Каждое устройство монтируется на виртуальную шину. Каждый драйвер реализует необходимые обработчики подключения и отключения устройства, управления питанием и т.д. Существующая сейчас возможность резервировать любые порты ввода-вывода и линии irq а также читать и писать конфигурационное пространство любых PCI устройств закрывается. По крайней мере для драйверов пользовательского режима. Все подобные операции осуществляются только с учётом ресурсов, используемых устройством.

Ещё один большой шаг вперед! И пусть ещё кто-нибудь попробует сказать, что в Колибри принципиально невозможно что-то сделать.

Возникли некоторые вопросы.
1. Диспетчер устройств - это обычный процесс без каких-либо привилегий правильно? Если так, что будет если его убьют?
2. Как драйвера будут общаться с диспетчером?
3. После второго этапа, как будет осуществляться доступ к PCI, IRQ и портам?
4. Реализацию управления питанием устройства и динамическое подключение.отключение со стороны драйвера можно будет отложить или необходимо будет реализовать сразу?

Гм...
тут сумненья возникли-с...

1) сейчас новый бранч Kolibri-acpi уже находится 1-м этапе, а остальные два - еще впереди, или я что-то не так понял?

2) аналогичной функциональности сейчас можно добиться и в транке (pcidev + Ghost-патч)?

3) с предложенным вторым этапом развития дескоп-системы согласен на 100%. Для embedded-версий этот путь не годится. Налицо форк проекта. Это не плохо и не хорошо - это (имхо) уже назревшая "взрослая" стадия развития Системы.

4) насчет 3-го этапа. А как быть с хотплагом и устройствами, которые BIOS по какой-то причине не смог определить? Сможет ли драйвер их увидеть при такой организации подсистемы?

art_zh wrote:1) сейчас новый бранч Kolibri-acpi уже находится 1-м этапе, а остальные два - еще впереди, или я что-то не так понял?

2) аналогичной функциональности сейчас можно добиться и в транке (pcidev + Ghost-патч)?

C pcidev аналогичной функциональности не добиться, так как он не работает с драйвером ACPICA в отличие от диспетчера. А текущий функционал и предлагается тестировать на транк версии с патчем Ghost'а. В архиве драйвер ACPICA, диспетчер и пример лога.

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

Asper

1.На данный момент это обычный загружаемый сервис в пространстве ядра. Его нельзя убить.
2. Точно ещё не определено. Если перевести все драйверы на PE диспетчер сможет экспортировать ключевые функции.
3. Резервирование портов будет происходить аналогичным образом, только запрос будет обслуживать диспетчер устройств. Оперции с битовой картой портов останутся в ядре. Обработка irq изменится. Нынешние функции пользовательского режима для большинства устройств просто бессмыслены. Для каждого вектора будет вызываться цепочка обработчиков. Если в этой цепочке будет обработчик из user-mode то вектор маскируется в apic, а потоку отправляется соответствующее событие. В конце пользовательский обработчик должен вызвать специальную функцию и сообщить ядру что прерывание обработано, иначе вектор останется замаскированым. Конечно при такой схеме латентность обработчиков будет значительной, зато можно писать драйверы работающие в пользовательском режиме и "играть в микроядро". И делать пошаговую трассировку обработчиков прерываний в самой Колибри.
4. Это будет зависеть от выбранной драйверной модели. Я специально не детализировал последнюю часть потому что смогу занятся ей не раньше февраля. Так что у форумных теоретиков и любителей всё детально проектировать есть четыре месяца на разработку API. Если ничего толкового не предложат сделаю по своему разумению. Не взыщите.

art_zh

Патч Ghost-a застопорился во многом из-за проблем с определением векторов irq в режиме ioapic. Текущий код в devman решает эту проблему. Он будет работать и с pic, но если номера векторов известны точно, глупо не использовать apic.
4. Это опять зависит от будущей драйверной модели. Если железо способно сообщить о подключении и отключении нового устройства то драйвер шины должен получить событие. Что он будет делать дальше - вопрос.

Для embedded-версий этот путь не годится. Налицо форк проекта. Это не плохо и не хорошо - это (имхо) уже назревшая "взрослая" стадия развития Системы.
Что я слышу???? embedded версия официальной? Нет? Тогда извините, но лучше бы Вы этого вообще не говорили. Вот когда embedded направление официально станет главным направлением КОС - пожалуйста. А извините, говорить что сейчас десктоп - это форк направление -- крайне возмутительно.
И если уж на то пошло, то embedded версия должна быть форком, но никак не десктоп.

maximYCH
- остынь.
- перечти сабж еще раз.
- спокойно пораскинь мозгами.

И не путай бранч с форком. Kolibri-HD - это бранч основного ядра.
А МеОС и КОС - это форк старого проекта на 2 (почти) независимые ветки, которые никогда уже не сольются в одно русло.

Бегло посмотрел devman на svn. Пока еще не компилил.
Код читается легко (легче чем сорцы линукса), хотя очень сильно чувствуется привязка к линуксовской структуре модулей. Еле разыскал где находится pci.h (оказалость что в \drivers\include\linux\, как и многое другое).

У меня тут созрел такой вопрос (не только к автору, но и ко всем коллегам): а может сразу отказаться от древнего доступа к конфигурационному пространству через порты?
PCIe-пространство сейчас есть на всех более-менее новых платформах, и уж если все равно заморачиваемся с ACPI, то и единый доступ к нему можно будет получить для всех платформ.
Такой подход не только резко упростит код (вместо call pci_read_config_word можно обойтись одним mov ax, word[dev_config+reg_offs]), но и позволит унифицировать доступ к конфигспейсу всех устройств.
Про ненужные задержки ввода-вывода я вообще не говорю.

art_zh

Есть ещё много старых систем. Сам на такой сижу. pci_read_config_xxx должна скрывать реализацию доступа.

pci_read_config_xxx(pci_dev)->pci_bus_read_config(pci_dev->bus)->raw_pci_read_config(pci_bus). Последняя является виртуальной функцией и перегружается в зависимости от механизма доступа и типа шины. Конечно немного громозко по сравнению mov ax, word[dev_config+reg_offs]), но это как раз и есть унификация доступа.

Есть и ещё причины.
1. Функция проверяет reg_offs на выравнивание и на максимальное значение.
2. Синхронизация доступа. Актуально при работе через порты.
3. Права на доступ. В данном случае надо получить структуру pci_dev, что не даёт сканить всё подряд.

А можно поинтересоваться, к каким именно системам применимо понятие "старая" в данном контексте?

Freeman

Видимо к системам без PCI Express.

Не совсем так - все новые чипсеты имеют встроенный механизм конфигурации PCIe extended config даже при физическом отсутствии слотов PCI express. В чипсетах АМД, например, связь между мостами аппаратно реализована через PCIe x4.

В "старых системах" доступ к конфигурационному пространству устройств производился исключительно через порты 0xcf8-cfc, покрывая только 1кб конфигурационного пространства для каждого устройства.
Новый механизм использует MMIO и резервирует 4к на устройство.

Serge
1. MMIO-доступ никогда не пересекает границы конфигспейса данного устройства и всегда выровнен по DW и DD
2. Не кэшируется и не конфликтует с параллельными запросами (что вполне естественно, ведь это лишь другая обертка того же самого конфигурационного цикла шины)
3. Пункт засчитан. Хотя ничто не мешает маппить MMIO блоками (1 bdf = 4к) и передавать пользователю линейный адрес.
Но тогда - от меня:
4. MMIO конвейеризируется и не ломает кэш (само собой, при соблюдении когеррентности шины).

art_zh

Не надо меня за советскую власть агитировать Я сам делал MMIO доступ для AC97 там где он есть. И тоже через виртуальные функции, чтобы один код работал везде. Там, где шина может работать через MMIO, будет работать. Со временем. Но для драйверов способ доступа должен быть однотипным. Фактически это HAL.

По поводу старой модели доступа к PCI и новой - почему бы не сделать условную компиляцию - где надо скомпилировать по старой модели доступа, а где можно - по новой?