Насколько я знаю, в Real-Time системах на выполнение прерывания отводится фиксированное время.

Опа!

Вообще-то, я лично считаю, что Линукс для не слишком mission-critical задач управления аппаратурой вполне подходит (избегаю упоминания о RT так на LOR много психолингвистически закодированных на это словосочетание субъектов).
Тут две засады - первое так никто не делает. Предпочитают в обработчике прерывания зафиксировать факт получения прерывания (тем более что не все операции вы можете проделать в самом обработчике - например нет никакой передачи данных в/из user space) и быстро из него выйти, предоставляя sheduler-у завершить необходимые действия в удобный для него момент.
Второе - это time granularity ядра. У Линукса она 100Гц (jiffies), так что ответ на любое событие не может поступить раньше чем через 0.01 c (с другой стороны - этот параметр можно варьировать, задавая величину HZ)

А в каких пределах можно нагружать обработчик прерывания?

Ведь можно выполнить простую обработку данных и среагировать на них.

А данные для user space можно сложить в памяти для драйвера, который отдаст их в user space.

Так можно делать? В каких пределах можно нагружать обработчик?

С Уважением Андрей.

>>>Ведь можно выполнить простую обработку данных и среагировать на них.
>>>А данные для user space можно сложить в памяти для драйвера, который отдаст их в user space.
Ладно. Но это означает, что всю логику управления вы реализуете внутри ядра (со всеми вытекающими отсюда последствиями - а именно, про glibc со всей ее математикой и string-conversion можно забыть/забить). Если это не пугает, то обработчик прерывания не прерываем - если завис он, то зависло все.

Мое IMHO:
Вы правильно делает что не упоминаетет RT. Так как по моему мнению
ваши утверждения в корне не верны и ошибочны.

СРВ - аппаратно-программный комплекс, реагирующий в предсказуемые времена на непредсказуемый поток внешних событий.

Это определение означает, что:

* Система должна успеть отреагировать на событиe, произошедшее на объекте, в течение времени, критического для этого события (meet deadline). Величина критического времени для каждого события определяется объектом и самим событием, и, естественно, может быть разной, но время реакции системы должно быть предсказано (вычислено) при создании системы. Отсутствие реакции в предсказанное время считается ошибкой для систем реального времени.
* Система должна успевать реагировать на одновременно происходящие события. Даже если два или больше внешних событий происходят одновременно, система должна успеть среагировать на каждое из них в течение интервалов времени, критического для этих событий.


Другими словами если система ГАРАНТИРУЕТ обработку события в течении
времени приемлемом для данного процесса то это ОСРВ, иначе нет.
Для систем, например, следящим за процессом который длится 1000 лет
реакция в 1 день может считаться РВ.
Все дело в ГАРАНТИИ. Дает ли ОС такую гарантию или нет.
Насколько я знаю Linux такую гарантию не дает. А значит linux не rtos.

> Процессор выполняющий программу получает прерывание. Он сохраняет
> данные текущей программы и переходит к обработчику данного прерывания.
> В этом обработчике он может передать данные переферии(т.е среагировать
> на прерывание почти немедленно).

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

geekkoo:
>  Тут две засады - первое так никто не делает.

почему же, делают, как раз когда нужно минимальное время реакции.

> Предпочитают в обработчике прерывания зафиксировать факт получения прерывания
> предоставляя sheduler-у завершить необходимые действия в удобный для него момент.

не совсем так. только, если мы явно сигнализируем какому-то процессу.
softirq выполняется обычно без участия планировщика. только, если
do_softirq не "успевает" выполнять pending requests.

> Второе - это time granularity ядра. У Линукса она 100Гц (jiffies), так что
> ответ на любое событие не может поступить раньше чем через 0.01 c

совершенно не так. HZ здесь _абсолютно_ не при чем. к тому же, HZ == 1000
в 2.6. Даже если мы пробуждаем user-level процесс, задержка определяется
тем, сколько времени текущий процесс (если у него меньший приоритет)
будет находиться в unpreemptible состоянии. но это время, к сожалению,
также unpredictable.

To fugrik.

Процесс вы описали верно.

Но по Linux not real-time наверное несовсем.

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

Адрес обработчика можно задать любой(и Linux здесь ничего не испортит). Переход по прерыванию должны гарантировать фирмы Intel, AMD и д.р.

Если я ошибаюсь, пожалуйста, просвятите меня.

С Уважением Андрей.

To: fighttort

"Процесс вызова обработчика прерывания он аппаратного уровня. Процессор выполняет некую программу, потом происходит прерывание распределённое для него(оно включено). Процессор бросает текущую задачу, сохраняет в стеке адрес места где он в ней остановился и переходит на вектор прерывания(место , которое содержит адрес обработчика прерывания)."

Вот это я совсем не понял. Почему процессор будет бросать задачу???
А приоритет прерывания? А если прерываний несколько???
А я еще раз повторю: ГАРАНТИРОВАТЬ.
Понимаете ядро линукса не гарантирует обработку прерывания в заданное
время. Спроектировано оно так. В ОСРВ во главу угла ставится ВРЕМЯ.
Ну сами посмотрите: наплодите процессов записи-чтения с винта. И у вас весь линукс уйдет в своп. И о каких гарантиях идет речь???

> А я еще раз повторю: ГАРАНТИРОВАТЬ.
> Понимаете ядро линукса не гарантирует обработку прерывания в
> заданное время. Спроектировано оно так. В ОСРВ во главу угла
> ставится ВРЕМЯ.

здесь вы совершенно правы

> А приоритет прерывания? А если прерываний несколько???

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

> И у вас весь линукс уйдет в своп. И о каких гарантиях идет
> речь???

это уже без разницы, linux, или ОСРВ. если процесс в свопе,
(точнее, часть кода/данных необходимые для реакции), быстро
его не добудишься.

согласен.
Смысл всех моих этих изысканий был в том чтобы показать,
что ОСРВ должна гарантировать время реакции, чего в linux нет.

"это уже без разницы, linux, или ОСРВ. если процесс в свопе,
(точнее, часть кода/данных необходимые для реакции), быстро
его не добудишься." IMHO вы здесь тоже не правы, быстро или медленно
не важно, важно чтоб в приемлимое время. Т.е. если разработчики
системы говорят что, например прерывание будет обработано не поздее чем через n минут(секунд,часов,лет). То чтобы не произошло это время
должно быть выдержено.

Люди.

В процессоре прерывания имеют "аппаратный" приоритет.

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

> > быстро его не добудишься.
>
> IMHO вы здесь тоже не правы, быстро или медленно
> не важно

согласен. просто я не знаю RTOS которая работает
с свопом, предоставляя временные гарантии. обычно,
если swap вообще поддерживается, предполагается
mlock().

> В процессоре прерывания имеют "аппаратный" приоритет.

http://www.linux.org.ru/view-message.jsp?msgid=611206&anonymous=hide

Я не совсем понял про ack

Могу я прерывание себе распределить не вызовом функции ядра, а собственной программой из ядра так, чтобы этот ack в обработчик не встроился?

С Уважением Андрей.

Реальное время - это не "почти немедленно", а ГАРАНТИРОВАННО в заданный (не обязательно короткий) промежуток времени.

Да я вроде и не спорю. Почти немедленно, в смысле очень быстро.

> Реальное время - это не "почти немедленно", а ГАРАНТИРОВАННО в заданный (не обязательно короткий) промежуток времени.

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

Справедливо ли в таком случае говоирть о ОС реального времени, скорее система в целом.

Если вернуться именно к ОС что же делает из rtos-а rtos? ну есть механизмы и правила совокупность которых обеспечивают гарантированный отклик, ответят производитиели RTOS. Фишка в том что даже в винде сегодня все эти механизмы реализованы. TROS - это просто маркетинговое, ракламное слово. Если у меня высокоприоритетный процесс что то активно считает, а низкоприоритетному пришло прерывание, никакая RTOS мне не поможет, дать гарантированный отклик, поможет только приоритет второй задачи задрать, а это я под чем угодно сделать могу.

Ужыс.

Пысец. Диалог двух зомби. При магическом заклинании RT в Линуксе в мозгах что-то щелкает, глаза стекленеют и пальцы сами собой выводят - "если система ГАРАНТИРУЕТ обработку события в течении времени приемлемом для данного процесса ". После чего программа извлекает из кэша слово QNX.
Исходные условия задачи читаем? Про user-level забудем, тк всю обработку предполагается делать в ядре.
>>Даже если мы пробуждаем user-level процесс, задержка определяется
тем, сколько времени текущий процесс (если у него меньший приоритет)
будет находиться в unpreemptible состоянии.
Вы это про Линукс или про что рассказываете? Это как так user-level процесс находится в unpreemptible состоянии? Или вы это про Win98?
>>> если мы явно сигнализируем какому-то процессу. softirq выполняется обычно без участия планировщика. только, если do_softirq не "успевает" выполнять pending requests.
Кто у нас выполняет wake_up_interruptible? Дядя Пушкин или планировщик?
>>>inux, или ОСРВ. если процесс в свопе, (точнее, часть кода/данных необходимые для реакции), быстро его не добудишься.
Кто у нас в свопе? Ядро?!! А-А-А! Держите меня четверо!
Если у нас user-level процесс в свопе, модуль сетевой карты перестает получать пакеты с веревки? Какая вам разница что у вас в свопе? Если обработчик прерываний вызван, то он будет выполнен до последнего return. Прервать его все равно никто не сможет.
Кто вам не гарантирует время отклика на прерывания? Понял, закодировали вас так. А если я повешу на таймер обработчик, который каждые 10 jiffies будет проверять порты интересующего меня устройства, и при обнаружении состояния требующего обслуживания, выполняю нужные мне действия? Все равно время реакции у меня не будет гарантированно равно 10jiffies=0.1c?

> Пысец. Диалог двух зомби.

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

> Исходные условия задачи читаем? Про user-level забудем, тк всю обработку
> предполагается делать в ядре. 

кем предполагается? если всю обработку делать в обработчике прерывания,
немного остается смысла в обсуждении вопроса: чем linux не RTOS.

> > Даже если мы пробуждаем user-level процесс, задержка определяется
> > тем, сколько времени текущий процесс (если у него меньший приоритет)
> > будет находиться в unpreemptible состоянии.
>
> Вы это про Линукс или про что рассказываете? Это как так user-level
> процесс находится в unpreemptible состоянии?

user-level process может выполнять системный вызов. если не CONFIG_PREEMPT
он уже не может быть вытеснен. в противном случае он может, например, держать
spinlock или каким-то иным способом иметь ненулевой preempt_count.

> Или вы это про Win98?

про windows мало что знаю, к сожалению. а в реализации этих механизмов
в linux, в то числе irq/softirq принимал некоторое участие.

> > если мы явно сигнализируем какому-то процессу. softirq выполняется
> > обычно без участия планировщика. только, если do_softirq не "успевает"
> > выполнять pending requests.
>
> Кто у нас выполняет wake_up_interruptible? Дядя Пушкин или планировщик? 

насчет Пушкина не уверен, но явно не планировщик. и причем здесь
wake_up_interruptible? если вы про ksoftirq thread, то, как пишут
на буржуйских форумах, RTFC.

> > если процесс в свопе, (точнее, часть кода/данных необходимые для реакции),
> > быстро его не добудишься.
>
> Кто у нас в свопе? Ядро?!! А-А-А! Держите меня четверо!

да вас и вдесятером не удержишь... почему же ядро, если я писал "процесс" ?

> Если у нас user-level процесс в свопе, модуль сетевой карты перестает получать
> пакеты с веревки? Какая вам разница что у вас в свопе?

не перестанет. но если ваша задача состоит в том, чтобы tcpdump
работал в реальном времени, а он весь swapped, какая вам разница,
что модуль сетевой карты исправно работает?

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

может, другое прерывание.

> Кто вам не гарантирует время отклика на прерывания?

linux не гарантирует, кто же еще. ide подсистема без DMA
может запрещать прерывания очень надолго, ~50 ms. например.

> А если я повешу на таймер обработчик, который каждые 10 jiffies будет проверять порты > интересующего меня устройства, и при обнаружении состояния требующего обслуживания, выполняю > нужные мне действия? Все равно время реакции у меня не будет гарантированно равно > 10jiffies=0.1c?

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

Пребываю с должным почтением вам, милостивый Государь мой.

> Я не совсем понял про ack

если говорить _очень_ грубо, и технически не совсем
корректно, то дело обстоит так.

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

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

можете, но это вам совсем не нужно.

> чтобы этот ack в обработчик не встроился?

теперь я не понял :)

Опа!

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

Ладно, прошу прощения, больше не буду ;)

>>>если всю обработку делать в обработчике прерывания, немного остается смысла в обсуждении вопроса: чем linux не RTOS.

Почему же немного? Ядро=Linux=OS. Делаем суперзаточенную под конкретную задачу систему, где все интересующие нас функции находятся в ядре. >>>Прервать его все равно никто не сможет. >>может, другое прерывание.

А что с первым-то будет? Процессор у нас же один. Ядро не preemptible. Цытата из LDD2 (стр. 269):

Often a substantial amount of work must be done in response to a device interrupt, but interrupt handlers need to finish up quickly and not keep interrupts blocked for long. These two needs (work and speed) conflict with each other, leaving the driver writer in a bit of a bind.

Т.е. при обработке прерывания другие прерывания блокируются.

>>>причем здесь wake_up_interruptible? если вы про ksoftirq thread, то, как пишут на буржуйских форумах, RTFC.

Я тут можно сказать сплю на распечатке LDD2, а меня RTFM-иться посылают (C - это описка или code?). Как же при чем. Из user-level пытаются читать данные, обработчик read данных не находит и засыпает до лучших времен, в ожидании поступления данных с девайса, в момент получения данных на девайс генерируется прерывание, обработчик прерывания извлекает данные из железки и в конце вызывает wake_up_interruptible, обработчик read просыпается и шлет данные в user-level. LDD2 стр. 264-265.

>>>ide подсистема без DMA может запрещать прерывания очень надолго, ~50 ms. например.

Да, cli это аргумент.

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

А об этом речи не шло. Требуется гарантированное время отклика. Согласен решение с таймером не масштабируется на малые времена отклика, но гарантированный отклик в пределах нескольких jiffies дает.

>>> HZ здесь _абсолютно_ не при чем.

Так мне что - мою распечатку LDD2 можно с чистой совестью на помойку выбросить? LDD2 стр. 181:

Timer interrupts are generated by the system's timing hardware at regular intervals; this interval is set by the kernel according to the value of HZ.

Или мы просто о разных ядрах говорим?

> А что с первым-то будет? Процессор у нас же один. Ядро не preemptible.

ядро 2.6 preemptible, если CONFIG_PREEMPT. но это _не_ имеет отношения
к препываниям.

> Цытата из LDD2:
> but interrupt handlers need to finish up quickly and not keep interrupts
> blocked for long.

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

еще раз. прерывания в обработчике разрешены, если request_irq()
был без SA_INTERRUPT (этот флаг можно смело считать анахронизмом).
Блокировано (disabled) только текущее прерывание, чтобы избежать
повторного входа в один и тот же обработчик.

> > причем здесь wake_up_interruptible?
>
> Как же при чем. ... обработчик прерывания извлекает данные из
> железки и в конце вызывает wake_up_interruptible

это все верно, но это в случае, как я писал:
> только, если мы явно сигнализируем какому-то процессу.
я имел в виду, что softirq (bottom halves) работают,
как правило без участия планировщика.

наверное, мы не поняли друг друга.

> C - это описка или code?

это code, ага

> > HZ здесь _абсолютно_ не при чем.
>
> Timer interrupts are generated by the system's timing hardware at
> regular intervals; this interval is set by the kernel according to
> the value of HZ.

timer resolution не имеет отношения к wakeup/interrupt latency.
вы можете изменить HZ = 1, это не окажет никакого влияния на
время, которое требуется для, например, пробуждения процесса
в приведенном вами выше примере чтения с устройства.

кстати, есть tickless патчи для linux. в таком режиме у нас
вообще нет этого регулярного таймера.

Извините что вмешиваюсь но IMHO эту тему (не тред, а именно тему "RTOS ли Linux или нет?") давно пора в топку.

>кстати, есть tickless патчи для linux. в таком режиме у нас >вообще нет этого регулярного таймера.

IMHO, в этих словах все сказано :) Вообще обсуждать параметры open source софта нет смысла, ибо либо есть патч, либо будет :)

ЗЫ. А так интересный разговор у вас получился, конструктивный и вежливый :) приятно такое увидеть на LORе :)

Получается так:

1. Ядро создаёт некий программный интерфейс для прерываний. Он состоит в следующем: При определении обработчиков для прерываний, ядро в вектор прерывания заносит адрес своего короткого обработчикак, который при его выполнении выставляет для ядра флаг, что прерывание было, и говорит устройству, что оно услышано. Потом быстро выходит из перывания.

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

Реальный маленький обработчик --флаг--> программа интерфейс --вызов--> мой обработчик заданный через функцию ядра.

Так? Я правильно понял?

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

Если нет, просвятите пожалуйста.

С Уважением Андрей.

А нужно ли?

Насколько я понял вас и idle-а, вы не хотите подтверждать прерывание с помощью ack, с тем чтобы interrupt controller не принимал другие прерывания, пока вы обрабатываете свое? Но вы имеете то же самое поведение, если вызываете cli или вызываете request_irq с флагом SA_INTERRUPT. Насколько я понял, в этом случае прерывания не теряются (по крайней мере с точки зрения процессора, будет ли при этом девайс по-прежнему генерировать прерывания зависит от устройства девайса), просто их reporting процессору откладывается на неопределенное время. Если же без SA_INTERRUPT - то имеем что-то типа LIFO (last-in-first-out) - прерывание, которое пришло последним, обрабатывается первым. Т.е. аппаратно все устроено таким образом (preemptible у нас ядро, не preemptible - без разницы - против лома нет приема), что при получения прервания, все равно что bottom-, что top-half обработчика прерываний (пусть будет process_irq1), исполняемые в данный момент времени, останавливается, из вектора прерываний вызывается эта штука с do_IRQ, которая в свою очередь вызывает top-half обработчика для вновь полученного прервания (process_irq2). Если в процессе работы новых прерываний не поступает, то этот top-half (process_irq2) благополучно завершается, после чего возобновляется выполнение предыдущего обработчика (process_irq1). Так что process_irq1 будет обработан после process_irq2.

Со слов idle и ваших я стал думать, что происходит так:

У ядра на каждое прерывание есть свой маленький обработчик. Все обработчики почти одинаковы.

У обработчика есть свойства: 1. Он вызывается когда происходит прерывание. 2. Он нужен для лишения прерывания "аппаратного" уровня. Т.е. его задача выставить бит в памяти(бит говорит о наличии прерывания), для программы которая в ядре отвечает за прерывания. 3. Т.к. во время его работы другие прерывания запрещены, он должен делать всё это быстро, чтоб если немного спустя этого прерывания приходит другое, то оно будет длиться какоето время. На него можно будет среагировать, если текущее прерывание быстро обработать.

Это к тому, что idle говорил что в Linux прерывания не имеют приоритета. Получается просто создана модель, которая из аппаратных прерываний, делает флаги. А потом эти флаги обрабатывает ядро, разбираясь с устройствами не в обработчиках, а своей одной спец программой. Программой интерфейсом, между ядром и прерываниями). Это всё и вызывает медленную реакцию системы. А я спрашиваю: Если вместо одного из маленьких обработчиков(реальный обработчик прерывания), через вектор перераспределить прерывание на мой обработчик, то тогда ядро будет обрабатывать все прерывания, кроме моего. Мой обработчик может работать с устройством и говорить с драйвером так, что ядро будет работать как раньше, и разговаривать со всеми остальными устройствами.

Если я правильно всё понял то так. Тогда вопрос: Насколько может наглеть мой обработчик по коду, чтоб ядру не мешать?

Если нет, пожалуйста скажите, что не так.

С Уважением Андрей.

lightport:
> 2. Он нужен для лишения прерывания "аппаратного" уровня.

???? 

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

честно говоря, я не понял ничего.

> Это всё и вызывает медленную реакцию системы.

почему? где медленнo?

> А я спрашиваю: Если вместо одного из маленьких обработчиков(реальный обработчик прерывания),
> через вектор перераспределить прерывание на мой обработчик, то тогда ядро будет обрабатывать
> все прерывания, кроме моего.

да можно это сделать, можно. непонятно совершенно - зачем?
что вы выиграете? сделать все это правильно совсем не тривиально.

если вы где-то что-то можете ускорить, лучше (и намного проще)
напишите патч и отправляйте в lkml.

ничего лишнего в обработке прерываний linux не делает.

Я подумал, что обработчики прерываний в Linux применяются просто для того, чтоб записать в память, что прерывание было. А ядро потом посмотрит память, увидит что устройство хочет говорить, и вызовет настоящий обработчик.

Простите за флейм. Мне просто хотелось понять, как всё устроено.

С Уважением Андрей.

> Я подумал, что обработчики прерываний в Linux применяются
> просто для того, чтоб записать в память, что прерывание было.
> А ядро потом посмотрит память, увидит что устройство хочет
> говорить, и вызовет настоящий обработчик.

нет, ну что вы, неужели это я вас так запутал?

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

И ещё: Выигрывал я там real-time для одного устройства. Т.к. собственный обработчик гарантию даёт.

С Уважением Андрей.

> Выигрывал я там real-time для одного устройства. > Т.к. собственный обработчик гарантию даёт.

не дает.

Наверное вы правы. Совсем забыл про глобальную маску прерываний. Что делать? Как Linux заставить стабильно реагировать на прерывания от моего устройства(расчёт 1 микросекунда), и при этом чтоб Linux работал со всеми другими устройствами.

> Что делать? Как Linux заставить стабильно реагировать на
> прерывания от моего устройства(расчёт 1 микросекунда), и
> при этом чтоб Linux работал со всеми другими устройствами.

ох... ну никак. ну что значит, "со всеми" ? вот на моей
машине переключение vesafb консоли запрещает прерывания
на ~25ms (правда, linux 2.2). ну вот что вы с этим
сделаете?

1us мне вообще кажется уж слишком... что вы сами-то
собираетесь успеть сделать в обработчике за это время?
что за задача, даже интересно.

можете попробовать rtlinux, fsmlabs.com, кажется.

можете взять машину с двумя cpu, и один процессор
выделить исключительно под свой обработчик. тогда
вам никто не сможет помешать в 2.6 ядре - global_cli()
там уже нету, cpu будет принадлежать вам целиком.