Board.KolibriOS.org

Serge
Такой вариант годится для внутриядерного применения. Т.е., обработчик прерывания устанавливается в режиме ядра.
Позволять пользовательским программам работать с IRQ во-первых небезопасно, а во-вторых - практически невозможно с имеющейся моделью памяти.

Работа с IRQ из приложений в МеОС/Колибри осуществляется следующим образом:
1) резервируется IRQ, при этом ядру передается массив номеров портов, из которых нужно считать данные
2) в маске событий устанавливается соответствующий бит (16+номер IRQ)
3) Возникает IRQ, системный обработчик считывает заданные порты.
Для программы-владельца устанавливается событие.
4) Программа получает событие 16+#IRQ. какой-то системной функцией получает содержимое прочитанных портов.

Большая задержка связана с тем, что процессы в МеОС и Колибри построены в одну бесприоритетную очередь. Каждый из них может потреблять до 0,1 секунды. Таким образом, при полной загрузке задержка составит около 2,5 с.

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

VaStaNi
Протестировал, отчет выслал.

Иван Поддубный

Проблема в том, что порты нужно записывать. А когда речь идет о PCI устройствах, то необходимо обработать прерывание до того как контроллеру прерываний будет послана команда EOI, если этого не сделать то мы сразу получим новое прерывание и система просто не сможет нормально работать.



Подобная модель реализована в QNX и вполне нормально работает. Можно специально создать 16 сегментов TSS по одному на каждое прерывание IRQ. Драйвер запускается как обычная программа и устанавливает обработчик прерываний вызывая системную функцию InterruptAttach(IrqLevel, handler_proc). Когда происходит прерывание системный обработчик настраивает соответствующий TSS, записывает handler_proc в TSS.eip, pageDir в TSS.cr3 и переключает задачу вызовом call pword [irq_task]. Когда отработают все обработчики в списке система посылает контроллеру EOI.
Такая схема позволяет загружать и выгружать драйверы как обычные программы и обрабатывать прерывания в адресном пространстве драйвера. Как недостаток дополнительные затраты на инициализацию TSS и вызов задачи.

В любом случае будет ли драйвер грузиться в адресное пр-во ядра как в NT или нет, нужна какая то
приемлимая модель драйверов.

[/offtop] VaStaNi,а до тебя мое письмо с тестами AC'97 дощло ?
[\offtop]

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

А я - обычный программист,который понимает в общем виде структуру ядра,но не более того.Думаю я не один такой программист.

ПОЖАЛУЙСТА,продумайте модель драйверов,ато народ уже замучился её поднимать(покачто результат был нулевой).Надеюсь на этот раз народ будет по активнее,а результат ненулевой.

Спасибо всем откликнувшимся! Всем отписал ответы.
Теперь по поводу прерываний. На мой взгляд, надо двигаться как полководец к победе, последовательно и приоритетно, если уж начинать дело.
А зачит:
- однозначное понимание проблемы и необходимости решать, менять;
- глобально качественно менять и браться за глобальные перемены, это занчит, базироваться на серьезных знаниях, либо опыте или и то и другое, поэтому надо подходить реально к "кадровому" вопросу и реально-достижимой цели. Вывод- цель рихтуется под кадры и реальные сроки, эффект;
- во избежание простоя, застоя, упадка и т.п. надо НАЧИНАТЬ менять закладывая новые основы и принципы, которые Виллис СОЗНАТЕЛЬНО ИЗБЕГАЛ и ОБХОДИЛ СУРРОГАТНЫМИ МЕТОДАМИ, надо идти "в лобовую атаку";
- изложенный мною выше(а именно пропись в IDT фиксированных векторов обработчиков, закрепленных за одним единственным железом и отдача драйвером ядру нового сервиса железа(функции), а не пользовательского доступа к портам и прерываниям) прост, эффективен, понятен, даже гибок, т.к. система может иметь 5 вариантов обработчика, например, а перебрав их на предмет реального тест-ответа железки, оставить в работе именно правильно ответивший адрес обработчика...;
- работы глобального драйверного направления, выработки модели, не противоречат данной концепции, а лишь будут подкреплены и базироваться на оных, как принципиально так и результативно, т.к. НЕ делая ВООБЩЕ никакого драйвера ИМЕННО, как драйвера, а не приложения(и ему подобная реализация, принцип) ничего вообще не получишь и не продвинешься + откатка массы Vendor`озависимости и нюансы овладения ЛЮБОЙ железяки сильно расходуют и время и силы и здоровье если хотите. Наскоком эти дела вообще не двигаются, даже всем миром, поверьте! Только скурпулёзный труд, опыты и пробы, кучи висяков, чтение до опупения фирменных мануалов железок...
Ребята, проанализируйте хотя бы кадрово-профессиональный вопрос своих рядов, что, кем и как реально, а что нет.

VaStaNi

Вот только не надо ничего заране фиксировать и резервировать. Ядро не обязано знать какая железка какое прерывание использует. Это не его забота. Разные железки могут использовать одно прерывание. Это особенно характерно для PCI устройств.
Драйвер просто определяет присутствие "родного" устройства через вызовы PCI.
Считывает номер IRQ из конфигурационного пр-ва PCI и устанавливет на этот номер свой обработчик, используя системный сервис. Все, что требуется от ядра системы -
это дать драйверу такую возможность и обеспечить передачу управления при прерывании.
Не важно работает ли драйвер, как отдельная программа в стиле QNX или грузится в адресное пр-во ядра в стиле NT kernel-mode drivers, важно чтобы драйвер можно было загрузить и при необходимости выгрузить.

А я собирался драйвер звуковой карты прикручивать к разрабатываемой подсистеме в виде отдельной программы. В драйвере будет область с фиксированной структурой, где будут характеристики звуковухи и необходимые для звуковой подсистемы ссылки. После запуска будет происходить поиск железки, после чего будет обращение к 55 функции (подсистеме). Например:
mov eax,55
mov ebx,3
int 0x40
А дальше звуковая подсистема сама будет обращаться к вложенным в драйвер процедурам используя ссылки, которые находятся в области описывающую железку. По сути, драйвер будет состоять из: заголовка, описания, ссылок, основного цикла процесса и набора процедур. А можно сделать и многофункциональный драйвер, который, будучи запущенным как обычное приложение, выводил бы окно, где можно настроить железку.

А как будут передаваться данные между программой и драйвером, если они в разных адресных пространствах?

Сделать поддержку драйверов-программ 3его кольца:
а) сложно - нужно добавить в ядро довольно много кода
б) крайне неэффективно по скорости; мне даже страшно представить, что N раз в секунду будет происходить переключение задач со сменой адресного пространства...

А вот сделать установку обработчиков внутри ядра как предлагает Serge - имхо проще пареной репы.

А я разве сказал, что заранее резервировать?
Как раз и предполагается, что после того как:

система окончательно убедившись в правильности данного драйвера и фиксирует (не позволяет его менять приложениям и т.д.), закрепляет его ЗА этим устройством.

ну так об том то и речь, что ХОТЯБЫ ПОКА так - это уже развязывало бы "руки и ноги" драйверному развитию оси!

VaStaNi


Ну, это совсем другое дело!

Иван Поддубный писал



Я тоже думаю что это не самое удачное по скорости решение. Еще одна проблема взаимодействие с драйвером когда программа в одном адресном пространстве а драйвер в другом

Serge

Связь будет между программа-подсистема (неявная) и подсистема-драйвер (прямая). А процедуры в драйвере могут быть релоцируемыми и работать будут в абсолютном адресном пространстве. Т.е. та часть драйвера, которая выполняется как процесс работает в одном адресном пространстве, а вложенные в драйвер процедуры работают с абсолютными адресами.

Надо сделать DLL и всё получится. Кстати AC97WAV из комплекта KolibriOS 0.5.3.0b2 работает, но очень странно - при изменении громкости изменяется скорость звука, а также на разных форматах WAV32KHZ 8b Mono скорость получается ниже чем в нормальном, а кроме AC97 никакого звука нет. А при компиляции из исходников AC97WAV запускается и тутже выключается.

O01eg
В программе используется программное преобразование всех файлов к 48 Кгц, потому что менять частоту самого кодека мы пока не можем (для разных фирм разные способы). По этому, возможно, что в коде, внедренном мной, не совсем корректно идет преобразование некоторых частот.
Но вот насчет того, что при изменении громкости изменяется скорость - это я впервые слышу. Какой у тебя кодек: номер, фирма?
В исходники попали немного устаревшие файлы, но для нормальной работы нужно всего лишь изменить в файле meosfunc.inc данные для 68 функции на:
MF_INTERNAL_SERVICES = 68
ALLOC_PHYS_MEM =5
FREE_PHYS_MEM =6
SET_PHYS_BUFFER =7
GET_PHYS_BUFFER =8
После этого все становиться нормально.

Avance AC97 Audio
Размещение: PCI шина 0, устройство 31, функция 5, IRQ 17