Добрый день. Пишу драйвер для Linux под некую железку. Хотелось бы предоставить пользователю механизм реагирования на различные события в устройстве: в частности, там есть таймер, по срабатыванию которого приходит прерывание. Подскажите, пожалуйста, как наиболее красиво и удобно это реализовать.Пока мне видится такая схема: пользователь как-то (через ioctl?) регистрирует callback, а ядро в нужный момент дергает эту функцию. Правомерно ли вообще такое поведение? Что необходимо чтобы корректно вызвать userspace-код, а потом вернуться в ядро. Можно ли это делать из irq handler? Может быть что-то другое? Дергать семафор, также переданный посредством ioctl?
>Добрый день. Пишу драйвер для Linux под некую железку. Хотелось бы предоставить
>пользователю механизм реагирования на различные события в устройстве: в частности, там
>есть таймер, по срабатыванию которого приходит прерывание. Подскажите, пожалуйста, как наиболее
>красиво и удобно это реализовать.
>
>Пока мне видится такая схема: пользователь как-то (через ioctl?) регистрирует callback, а
>ядро в нужный момент дергает эту функцию. Правомерно ли вообще такое
>поведение? Что необходимо чтобы корректно вызвать userspace-код, а потом вернуться в
>ядро. Можно ли это делать из irq handler? Может быть что-то
>другое? Дергать семафор, также переданный посредством ioctl?Я бы сделал какой-то девайс (типа как bpf например), к которому бы коннектилась программа и считывала оттуда по мере поступления данные, например select'ом .. (or poll'ом).
>Пока мне видится такая схема: пользователь как-то (через ioctl?) регистрирует callback, а
>ядро в нужный момент дергает эту функцию. Правомерно ли вообще такое
>поведение? Что необходимо чтобы корректно вызвать userspace-код, а потом вернуться в
>ядро. Можно ли это делать из irq handler? Может быть что-то
>другое? Дергать семафор, также переданный посредством ioctl?
такое поведение НЕ ПРАВОМЕРНО к сожалению,
если уж так надо дёргать users callback то смотреть надо в сторону разных
RT расширений.
вообще-то про select Вам правильно сказали - делаете простой чар-девайс и вперед..добавите к нему самодельный ioctl чтобы пользователь мог диагностировать проблемы возникающие при чтении/записи и все будет ок.
с точки зрения пользователя это будет типичный цикл чтения/записи через select + обработка ошибок, к тому же с таким девайсом вполне смогут работать и все прочие приложения, а не только написанные вами для конкретной железяки и отлаживать такой драйвер проще.
>делаете простой чар-девайс и вперед..добавите
>к нему самодельный ioctl чтобы пользователь мог диагностировать проблемы возникающие при
>чтении/записи и все будет ок.Спасибо, так и поступлю. Про неправомерность моего варианта я уже понял - уже после того, как задал вопрос :).
Можно либо бросать сигнал, либо реализовать fasync для упомянутого chardev.Напрямую реализовать callback будет очень сложно, т.к. нужно грамотно понизить привилегии и вообще в режиме 4/4 для IA32 ядро работает в другом адресном пр-ве, поэтому самым прямым аналогом этого является сигнал (для некоторых типов устройств еще желательно RT).