Обработка прерываний в linuxrt

Обычно прерывание пробрасывается в userspace-прогу реализацией poll на спецфайле устройства. Можешь посмотреть драйвер rtc для примера.

в любом случае модуль понадобится.

> в любом случае модуль понадобится.

Формально - нет, хотя на практике - скорее всего.

Про Real-time патч везде сказано, что это мини-ядро, которое встраивается между аппаратной частью и ядром Линукс, запуская ядро Линукс как приложение с низким приоритетом. Все прерывания сперва попадают в РТ ядрышко а потом уже в ядро линукс Из этого я делаю вывод, что при написании модуля для этого мини-ядра возникнет столько гемора, сколько я не осилю в связи с отсутствием глубоких познаний о линукс впринципе. Посему спрошу, может кто-нибудь работал в этом патче и знает как там что делать?

> Про Real-time патч везде сказано, что это мини-ядро, которое встраивается между аппаратной частью и ядром Линукс, запуская ядро Линукс как приложение с низким приоритетом

Эээ... похоже, мы о разном говорим. Что такое «realtime-патч» - патч -rt от Molnar и Gleixner, или RTLinux от Yodaiken?

Из этого я делаю вывод, что при написании модуля для этого мини-ядра возникнет столько гемора, сколько я не осилю в связи с отсутствием глубоких познаний о линукс впринципе.

Для RTLinux ты, вероятно, прав. Но для -rt написанием модулей практически не отличается.

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

Я говорю про -rt патч А что означает практически не отличается? И если мне придется писать модуль ну и пускай, но тогда спрошу а как проще всего, а главное выдерживая принцип реального времени (т.е. для моей конкретной задачи все должно происходить с дискретой 1 мс без сбоев а то никакого толку от привода не будет) перебрасывать инфу из модуля в user приложение?

По поводу отказа от прерываний - это моя мечта, но есть 2 проблемы: 1) У АЦП есть время преобразования, если я отправлю запрос на преобразование и сразуже прочитаю не факт что что-нить получится. Делать какие-то искусственные задержки я не хочу, не красиво это и нестабильно 2) Если в этой конкретной задаче и получится избежать прерываний, то меня все равно не поймут коллеги с кафедры. Они под QNX сидят и их все устраивает, кроме того факта что QNX коммерческая ось, а если я скажу «вот ребята Линукс но смотрите вот здесь надо через ж сделать а здесь вот так выпендриться и все бут работать» меня не поймут.

> для моей конкретной задачи все должно происходить с дискретой 1 мс без сбоев а то никакого толку от привода не будет

А зачем тебе вообще прерывания? Таймера не хватит?

Делать какие-то искусственные задержки я не хочу, не красиво это и нестабильно

Гм, а вот пульсаудио сейчас наоборот избавляется от прерывания и переходит на таймера, именно по причине стабильности, и представляет это как новую фичу. Я вот подозреваю, что они знают, что делают.

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

А ты на них забей, скажи, что они ничего не понимают.

> а вот пульсаудио сейчас наоборот избавляется от прерывания и переходит на таймера

Таймера - это те же прерывания, но код доставки их из ядра в userspace уже написан :)

Таймера - это те же прерывания, но код доставки их из ядра в userspace уже написан :)

Вот именно, и это плюс. Потому что кривые железяки и драйвера алсы - это одно, а таймер - это как-то понадежнее будет. Но правда пока оно только для проигрывания, а не для записи, как у ТС. http://0pointer.de/blog/projects/pulse-glitch-free.html

А еще есть UIO http://www.kernel.org/doc/htmldocs/uio-howto.html, которое как раз вот для всяких АЦП и придумывали.