Можно использовать ядро 2.6.10 для real-time приложений?

есть такое решение - RTLinux точно можно собрать с 2.4 веткой

почитать к примеру можно здесь
http://linuxdevices.com/articles/AT8073314981.html

Насколько я знаю, RTLinux - это патчи для ядра + собственный скедьюлер, к-рый оперирует с idle-процессом ядра (pid=0) и ставит ему низший приоритет, в отличии от риалтайм-таска/тасков.

Но вот такая штука: ведь в ядре 2.4, в реализации скедьюлера есть поле структуры таска policy (равно как и p->rt_priority), к которому можно доступиться с помощью sched_setscheduler(...) и задать класс скедьюлера (установить значение поля policy) в SCHED_RR или SCHED_FIFO. И к тому же goodness для рт-задачи вычисляется путем прибавления 1000 к значению p->rt_priority. И вот как теперь вся эта логика вкладывается в требования риалтайм-системы? Достаточна ли она? Было бы, конечно, очень интересно протестировать задачи из тестов для RTLinux на ядре, скажем, 2.6.

Или все это лажа?

Спасибо.

> RTLinux - это патчи для ядра + собственный скедьюлер

это его sceduler работает только с "его собственными"
rt threads

> к-рый оперирует с idle-процессом ядра (pid=0) и
> ставит ему низший приоритет

я очень давно смотрел на это дело, но c idle процессом
там ничего не делается, кажется.

вы сами посмотрите этот patch, он очень (в сущности)
простой.

там есть детали типа unlazy page-fault in vmalloc area,
но все это детали, которые можно опустить.

> Но вот такая штука: ведь в ядре 2.4, в реализации скедьюлера
> есть поле структуры таска policy

все это даже на этом форуме столько раз обсуждалось, поищите.

коротко. да, планировщик поддерживает SCHED_RR/SCHED_FIFO.
но не существует оценки сверху для времени, когда этот rt
процесс _гарантированно_ получит CPU.

Еще дисковый шедулер (io requests scheduler) можно выставить elevator=deadline для RT систем

Буду краток. НЕТ.