Обработка IRQ

Kernel architecture questions
  • Нужен один вариант. Вопрос только который лучше и проще.
  • Если оставить первый вариант то про звук можно будет забыть до тех пор пока не появятся user-mode драйверы способные работать отдельным потоком в режиме реального времени. Пока таких не предвидется.
    Первый вариант похож на обработку IRQ в микроядре только реализован очень криво, особенно бестолковая ф.44. Второй расчитан на драйверы работающие в режиме ядра. При желании его можно объеденить с первым если вызывать irqhandler в тех случаях когда драйверный обработчик прерывания не установлен.
  • Кстати первый вариант в существующем виде не годится для обработки PCI IRQ. Они выставлены по уровню, а не по фронту как ISA. Поэтому надо или обработать прерывание или маскировать линию в PIC (как в minix3) до того как отправлять EOI.
  • Мне кажется, пора бы уже определиться. Конечно, сейчас это ещё не очень актуально, но лучше решать проблемы в момент возникновения, а не когда они начинают действовать на нервы.
    Я тоже предпочитаю драйверный подход, но переписывать ppp.asm не готов...
    Ушёл к умным, знающим и культурным людям.
  • diamond

    Тогда надо определиться каким должно быть ядро монолитным или микро. Потому что получается странно - половину прерываний обрабатывает ядро, другую могут обработать приложения, это IRQ 2,5,7,8,9,10,11 и 3 и 4 если не подключена СОМ-мышь. О проблемах с IRQ от PCI устройств я уже писал. Обработать проерывание от USB или AC97 в программе не получится.
  • мне хотелась ускорить работу сети.. как я понял нало переходить на прерывания. Насколько это реально в сетевом драйвере использовать?
  • SPraid

    Вполне реально. Для примера посмотри drivers/sceletone.asm - там заготовка для драйвера и код поиска нужного устройства на шине PCI и drivers/sound.asm - пример драйвера PCI устройства.
  • Четыре года достаточный срок, чтобы определиться.

    Поэтому в ближайшем будущем функции 41,42,44,45 будут удалены из ядра и вся обработка прерываний будет происходить только в ядре. Если вам необходимо отреагировать на Irq в user-mode, есть подсистема событий и функции create_event, raise_event, sys_getevent. Используйте их для доставки сообщения из обработчика прерываний.

    Вводятся разделяемые обработчики прерываний для правильной работы с устройствами PCI. (Не прошло и ...)
    Функция int attach_int_handler(int irq_line, void (*handler)(void), int access);
    меняется на int attach_int_handler(int irq_line, int (*handler)(void*), void *user_data); где user_data - данные пользователя, обычно указатель.
    возвращаемое значение - логичический номер обработчика.

    меняется формат обработчка прерываний
    вместо текущего void irq_handler(void);
    на int __cdecl irq_handler(void *user_data);
    Spoiler:К.О. напоминает что соглашение __cdecl требует сохранения регистров ebx, esi, edi, ebp
    Обработчик должен возвратить ненулевое значение если прерывание было от устройства, в противном случае 0. Обработчики прерыванией ISA устройств должны всегда возвращать ненулевое значение. Для каждой линии irq будет вестись подсчёт числа необработанных прерываний. При превышении некоторого лимита линия будет маскироваться.

    Заглушка
    void detach_int_handler(void){};
    меняется на
    int detach_int_handler(unsigned int handle);
    где handle логический номер обработчика, установленного функцией attach_int_handler

    Детали реализации.
    Для хранения информации об обработчиках вводится структура

    Code: Select all

    struc IRQH
    {
       .list            LHEAD  ; linux like list head
       .handler         dd ?   ;handler roututine
       .data            dd ?   ;user-specific data
       .sizeof:
    }
    Обработчики прерываний для одной линии объединяются в двусвязные списки. При наступлении прерывания ядро устанавливает флаг необработанного irq в битовой маске и последовательно вызывает каждый обработчик из списка. Если обработчик возвращает ненулевое значение ядро сбрасывает флаг irq. После того, как были вызваны все обработчики, ядро проверяет флаг irq и увеличивает счётчик ошибок если флаг не сброшен.
  • Хорошо, давно пора. В транке это будет и если да, то когда?
    Сделаем мир лучше!
  • Изменения будут вводится постепенно. Сначала будут исправлены обработчики прерываний у существующих драйверов. Потом удалены функции 41,42,44,45 и добавлены расшареные обработчики. Через некоторое время будет сделано маскирование линий. Предварительная версия залита в бранч kolibri-acpi. У себя проверял совместную работу usb и видеоплеера с акселерацией. Всё нормально.
  • Serge
    Правильно, сейчас обработка IRQ - это смесь шарады с лотереей.
    Только надо не забывать, что еще есть мультивекторные устройства, и [по мере роста популярности MSI] их будет все больше и больше.
    Serge wrote:Если вам необходимо отреагировать на Irq в user-mode, есть подсистема событий и функции create_event, raise_event, sys_getevent. Используйте их для доставки сообщения из обработчика прерываний.
    Для обработки MSI одного факта события мало - нужно еще и передать обработчику сам 16-битный мессидж.
    Или предусмотреть для каждого устройства импорт списка обработчиков всех возможных векторов.
    Serge wrote:Для каждой линии irq будет вестись подсчёт числа необработанных прерываний. При превышении некоторого лимита линия будет маскироваться.
    При заморочках с MSI-запросами (а они могут быть совершенно феерические!) надо маскировать всё устройство, причем не только в APIC, но еще и в PCI-конфигспейсе. Операция примитивная, но для этого надо знать bdf-адрес устройства.

    Так что не забудь включить в attach_int_handler еще и bdf.
    Впрочем, ты же это делаешь для ACPI-ядра? Там ведь и bdf может измениться на лету!
  • art_zh

    Это для всех. На acpi пока проверяю.
    Ты меня озадачил. С msi нет проблемы дописать, обработчик __cdecl. А bdf добавить сложнее потому что attach_int_handler stdcall. Это придётся менять всё одновременно - ядро все драйверы и номер драйверной модели.
  • Serge
    Наверное, для MSI нужен будет отдельный формат запроса и хэндла. Я сейчас вообще не представляю как можно унифицировать обработчики MSI-запросов - они будут очень специфическими для разных устройств.

    Кстати, еще совсем недавно MSI ненавидели не только программисты, но и электронщики. В раннем стандарте PCI Express даже пришлось разрабатывать отдельные типы запросов - специально для эмуляции IRQ и INTA.

    Сейчас генеральная линия партии PCI-SIG называет эти запросы не иначе как "Legacy PCI interrupt" и настоятельно рекомендует разработчикам отказаться от них (также как и от портов ввода/вывода) и всюду переходить на MSI. В новых чипсетах, FPGA-ядрах и эндпойнт-чипах поддержка MSI реализована довольно удобно (с точки зрения электронщика), но программистам от этого легче не стало...
    Стало хуже - мы (разработчики) теперь совсем страх потеряли и можем запросто навесить на MSI-канал по 8, 32, а иногда даже 128 векторов! На каждый чих - свой мессидж; RT-шиза рулит. Очень удобно, и главное - думать не надо.
    Последний писк - устройства не только без IO-портов, но даже без MMIO. Все BARы пустые, управление - через регистры конфигспейса, данные грузятся сами собой (по DMA), а дополнительные функции настраиваются программно, через MSI-обработчики.
    И еще есть устройства, в которых MSI вообще не отображается на APIC, а просто пишет свои мессиджи в программно-доступный буфер. С ними ядру вообще ничего делать не надо, но с ACPI заморочки будут обязательно: энумератор для них развесит целую гирлянду APIC-каналов, а потом драйвер перемаппит мессиджи в свой буфер... или наоборот.

    В общем, делай как решил, под PCIe все равно перепиливать нужно очень многое, одной драйверной моделью здесь не обойдешься.
    Евангелие от Иоанна: стих 1

    Code: Select all

    ; В начале было Слово:
    B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • art_zh
    Думаю пока не надо мешать всё в одну кучу.
    Со стороны железки понятно, программируются регистры в pcicfg куда писать и что писать. А что происходит со стороны процессора ? Каким образом msi принимается контроллером прерываний ?

    Зашёл на сайт Intel поискать pdf-ы. Что они сделали с документацией ? Просто нет приличных слов.
  • Who is online

    Users browsing this forum: No registered users and 7 guests