реализация переключения "процессов" протекающих в ядре.

[ZeLLa]

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

Кто нибудь занимался реализацией задержек выполнения чего либо в ядре, что бы осуществить паузу в в выполнении текущей задачи и что бы она не только остановилась на время а передала там управление другим процессам внутри ядра - подскажите что и как делать?

[Portnov]

Искать по словам preemptible kernel.

[serzh-z]

ZeLLa
Для этого создаётся *поток ядра*, который выполняет список запросов. Постановкой запросов в некую очередь этого потока должен заниматься системный вызов, который вернёт задаче дескриптор, на котором она сможет повиснуть в ожидании.

[RasenHerz]

по-моему вы очень плохо читаете докуметацию =)
чтобы вызвать переключение процессов надо вызвать schedule(); если есть какая-либо другая задача, на которую надо выполнить переключение, то лучше всего использовать switch_to().
без включенного вытеснения в ядре, вам возможно будет действовать в двух основных направлениях:

1) Считать тики системного таймера непосредственно в коде модуля и следить за тем чтоб ваш код не отнимал слишком много времени.
2) Этим способом поступают нормальные люди) - проще всего организовывать очереди выполнения или тасклеты.

вот в таких направления можно работать. очень советую прочесть книгу Linux Device Drivers (она на английском) , найдете в ней много полезного.

[Serg79]

вот в таких направления можно работать. очень советую прочесть книгу Linux Device Drivers (она на английском) , найдете в ней много полезного.

Здесь все зависит от того что конкретно реализовано.

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

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

[RasenHerz]

тогда нужно узнать у автора будет ли его код исполняться в управляющем тракте ядра?

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

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

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

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