start_kthread

не вижу проблемы
создаем процесс ядра, который будет в цикле производить опрос устройства и класть полученные данные в буфер
read() в контексте пользовательского приложения будет читать данные из буфера
если данных нет - блокируемся (регистрируем процесс в очереди ожидания)
при получении данных делаем wake_up() процесса

С чтением нет проблем - оно производится по прерывынию
Проблема с записью в устройство: я даю данные на запись из userspace, а в драйвере порождаю поток ядра, который должен постоянно писать в устройство. Если я прервусь с отдачей - в канал пойдет "обрыв" данных. А прерыватся мне нужно - чтобы перерисовать и опросить интерфейс.
Для начала такой вопрос - почему поток ядра блокирует остальные потоки? Такое поведение нормально?
Причем такое поведение наблюдается если я не отдаю планировщику кванты времени через cond_resched.
А если отдаю - отдается слишком надолго.

> Для начала такой вопрос - почему поток ядра блокирует остальные потоки?

Видимо, потому что в 2.4 нет preemption'a

> Такое поведение нормально?

не нормально если процесс ядра не является процессом реального времени

> А если отдаю - отдается слишком надолго.

может, подойдет
schedule_timeout()?

> Если я прервусь с отдачей - в канал пойдет "обрыв" данных.

возможно, перед записью нужно вызвать preempt_disable() для запрета вытеснения
или устройство слишком медленное?

> Видимо, потому что в 2.4 нет preemption'a

а если более подробно, то в 2.4.x нет проверки TIF_NEED_RESCHED при возврате на 0-е кольцо из обработчиков асинхронных событий (исключения, прерывания)

делал так:
lock_kernel();
current->policy = SCHED_RR;
unlock_kernel();
поведение осталось таким же - "блокируется" все. клавиатура перестает реагировать, обновление top приостанавливается. после окончания потока передачи - можно дальше работать с системой.


schedule_timeout() не подойдет т.к. у нее минимальная задержка 1/HZ = 1/100, а мне нужны задержки 1/150 ... 1/8000

получается, что устройство настолько медленное, что работа с ним блокирует все остальные процессы на время, достаточное для того, чтобы заметить тормоза системы
получается, лучшего решения нет (кроме как 2+ ядерную машину использовать)

несколько непонимаю понятие "медленное"
оно скроее неправильное - требует непрерывного потока данных к передаче (данные вывожу в порт командой outb)
в железке нет бефера на передачу, потому и требуется постоянные опрос ее на готовность и передача очередного байта данных
основной момент, который я уяснил для ядра 2.4.х, это то что если в потоке ядра не отдавать кванты времени, то этот поток блокирует всю систему (а не только мое приложение)