Колибри для встроенных систем?
-
tsdima критические участки и так писались так что бы занимать как можно меньше времени, кто наблюдал такие задерки в 5-50сек???
Ghost
Кажется это была одна из модификаций L4. QNX для этого уже слишком "толстая".
Кажется это была одна из модификаций L4. QNX для этого уже слишком "толстая".
tsdima
Я не могу гарантировать что таких задержек нет. Но это не значит автоматически что они есть и будут вылезать всё время.
Я не могу гарантировать что таких задержек нет. Но это не значит автоматически что они есть и будут вылезать всё время.
Serge угу, OKL4 от Open Kernel Labs. Называется по умному formally-proven bug-free microkernel - микроядро с математически доказанным отсутствием ошибок.
Ghost
В этом много лукавства. Микроядро L4 настолько ужато что все ошибки выдавливаются в user-mode. Вот безошибочная система...
В этом много лукавства. Микроядро L4 настолько ужато что все ошибки выдавливаются в user-mode. Вот безошибочная система...
2tsdima:
Достаточно не отсутствия таковых "фокусов", а согласия коллег преодолевать эти проблемы по мере поступления.
Согласен
2Ghost:
От те раз...
А я думал наоборот, что это про меня... Ну ладно, это лирика
Конкретно
1) Давайте понимать существование 3-х уровней
Первый - это функционирование ядра (пусть условно это команда KoOS)
Второй - это разработчик системы (настолько же условно - это я)
Третий - это пользователи системы (это оператор и сисадмин в каком-нибудь Урюпинске)
2) Если система работает под моим чутким наблюдением - тоже нет вопросов. Как справедливо отметил коллега ДедОк - сносим все лишнее, и при запуске сторонних приложений я все понимаю про количество потоков
И совершенно спокойно можно работать с гарантиями реактивности в 100 мсек (ну не будет у меня больше 10 активных не спящих потоков).
И ни про какую винду мы такого сказать не сможем
Это тот случай, про который можно сказать "Да, вы попали по назначению"
Но согласитесь коллеги, это же не общий случай - это конкретная индивидуальная заточка
3) Другой разговор - в Урюпинске. Да, сегодня врядли народ найдет нечто ресурсоемкое да запуска на KoOS. Но это только сегодня, а мы же пытаемся говорить о нише применения. Там возможно абсолютно все, даже то, чего мы сегодня и не предполагаем.
Это закон природы такой, многократно практически проверенный
Вплоть до тупого многократного нажатия на иконку какой-нибудь проги (про которую я слыхом не слыхивал).
И ведь следов никаких не будет... Разовор будет: "А у нас ка-а-ак врезалось!!!!"
Вот тут-то и возникает цифра 2.56 (не путать с п.2, где мною все контролируется) - это количество потоков, которые физически сможет запузырить пользователь, хоть из трусов он выпрыгни.
4) Ну вот и все, Разработчик (по п.2) все понимает про функционирование оси. Разрабытывает систему под характеристики на конкретном компе, но он не может полностью контролировать события в Урюпинске, и испытывает от этого жуткий дискомфорт.
И его, разработчика, могло бы спасти наличие в оси неких возможностей планировщика.
Настолько, что я первый бы сказал - это на сегодня максимально адекватная ниша для KoOS. По причинам, которые давно как бы и перечислил:
И именно это было бы очень правильно............
5) Слушай, ну а чем не конкретная постановка в таком виде:
5.1) Появляется сис ф-я запроса параметра изохронности потока. Это одно целое - количество квантов, через которое гарантировано получение управления
5.2) Ось позволяет только один такой с системе. Новая сис. ф-я возвращает в результате успех или неуспех запроса
5.3) Ось крутит карусель штатным образом, пока не наступает время изохронного потока. Тут и происходит отклонение от штатного планирования понятным образом. При получении управления потоком - его счетчик устанавливается на ранее заданный максимум. На каждом временном кванте - счетчик уменьшается
Вроде и все...
Понятно, что конкретность - вещь субъективная. Ну давай уточним, делов-то
Может это и слишком упрощенная постановка...
Но в чем фокус: сделать этот стартовый шаг самостоятельно, сегодня, после 2-х месяцев знакомства с кодами - не хватает у меня еще наглости. Через полгодика - хватило бы, наверное...
А на продолжить, усложнить, экстремальные эксперименты - уже хватает
Но даже эта упрощенная постановка - дала бы мне средство для борьбы с шаловливыми ручками из Урюпинска
Может не для абсолютно любой задачи, но дала бы
Это же бы ли бы принципиально отличающиеся ситуации
Достаточно не отсутствия таковых "фокусов", а согласия коллег преодолевать эти проблемы по мере поступления.
Согласен
2Ghost:
От те раз...
А я думал наоборот, что это про меня... Ну ладно, это лирика
Конкретно
1) Давайте понимать существование 3-х уровней
Первый - это функционирование ядра (пусть условно это команда KoOS)
Второй - это разработчик системы (настолько же условно - это я)
Третий - это пользователи системы (это оператор и сисадмин в каком-нибудь Урюпинске)
2) Если система работает под моим чутким наблюдением - тоже нет вопросов. Как справедливо отметил коллега ДедОк - сносим все лишнее, и при запуске сторонних приложений я все понимаю про количество потоков
И совершенно спокойно можно работать с гарантиями реактивности в 100 мсек (ну не будет у меня больше 10 активных не спящих потоков).
И ни про какую винду мы такого сказать не сможем
Это тот случай, про который можно сказать "Да, вы попали по назначению"
Но согласитесь коллеги, это же не общий случай - это конкретная индивидуальная заточка
3) Другой разговор - в Урюпинске. Да, сегодня врядли народ найдет нечто ресурсоемкое да запуска на KoOS. Но это только сегодня, а мы же пытаемся говорить о нише применения. Там возможно абсолютно все, даже то, чего мы сегодня и не предполагаем.
Это закон природы такой, многократно практически проверенный
Вплоть до тупого многократного нажатия на иконку какой-нибудь проги (про которую я слыхом не слыхивал).
И ведь следов никаких не будет... Разовор будет: "А у нас ка-а-ак врезалось!!!!"
Вот тут-то и возникает цифра 2.56 (не путать с п.2, где мною все контролируется) - это количество потоков, которые физически сможет запузырить пользователь, хоть из трусов он выпрыгни.
4) Ну вот и все, Разработчик (по п.2) все понимает про функционирование оси. Разрабытывает систему под характеристики на конкретном компе, но он не может полностью контролировать события в Урюпинске, и испытывает от этого жуткий дискомфорт.
И его, разработчика, могло бы спасти наличие в оси неких возможностей планировщика.
Настолько, что я первый бы сказал - это на сегодня максимально адекватная ниша для KoOS. По причинам, которые давно как бы и перечислил:
Осталось добавить возможность задания характеристик "изохронности" для потока, и у Разработчика Системы появится инструментарий, позволяющий рассчитывать на то, что оператор из Урюпинска не только не сможет уронить систему, но и управляющую программу в составе системы.Быстр, вынослив, и кормить не надо....
Всякие рюшечки, прозрачности, полутени, майонез - оператору не нужны. Не боярин чай. У нас, вон, ему и интернет отключили специально
Необходимый набор инструментов - достаточно ограничен.
А вот работоспособность - оператору нужна.
Если ради этого не придется переделывать брак - оператор простит абсолютно все. Даже ДОС может стерпеть (проверенно)
И попадает это прежде всего в руки все-таки подготовленного пользователя (разработчика некой системы)
Ну все в тему получается
И именно это было бы очень правильно............
5) Слушай, ну а чем не конкретная постановка в таком виде:
5.1) Появляется сис ф-я запроса параметра изохронности потока. Это одно целое - количество квантов, через которое гарантировано получение управления
5.2) Ось позволяет только один такой с системе. Новая сис. ф-я возвращает в результате успех или неуспех запроса
5.3) Ось крутит карусель штатным образом, пока не наступает время изохронного потока. Тут и происходит отклонение от штатного планирования понятным образом. При получении управления потоком - его счетчик устанавливается на ранее заданный максимум. На каждом временном кванте - счетчик уменьшается
Вроде и все...
Понятно, что конкретность - вещь субъективная. Ну давай уточним, делов-то
Может это и слишком упрощенная постановка...
Но в чем фокус: сделать этот стартовый шаг самостоятельно, сегодня, после 2-х месяцев знакомства с кодами - не хватает у меня еще наглости. Через полгодика - хватило бы, наверное...
А на продолжить, усложнить, экстремальные эксперименты - уже хватает
Но даже эта упрощенная постановка - дала бы мне средство для борьбы с шаловливыми ручками из Урюпинска
Может не для абсолютно любой задачи, но дала бы
Это же бы ли бы принципиально отличающиеся ситуации
Galkov
Наглость - второе счастье.
P.S. Вышел R300 Gallium3D так что я пока занят.
Наглость - второе счастье.
P.S. Вышел R300 Gallium3D так что я пока занят.
Запуск "под моим чутким наблюдением" - это встроенная система, запуск в Урюпинске - это десктопная система? Раз опреатор может делать на ней все что угодно - то да. Если ты хочеш поставять свою систему в Урюпинск, то как вариант стартуеш свой процесс первым и просто не даеш возможности оператору запускать сторонние программы, это решаемая задача уже сейчас, в таком случае ты фактически получаеш систему запущенную "под моим чутким наблюдением".
Про изохронность. Для случая с только одним изохронным процссом задача легко решается грубыми методами, в виде правки core->shed.inc->irq0, добавляем туда условие и счетчик, первый запущенный процесс быдет иметь PID 1 (0 - система).
В таком виде для встройки решение оправдывается, для системы общего назначения нет.
Про изохронность. Для случая с только одним изохронным процссом задача легко решается грубыми методами, в виде правки core->shed.inc->irq0, добавляем туда условие и счетчик, первый запущенный процесс быдет иметь PID 1 (0 - система).
В таком виде для встройки решение оправдывается, для системы общего назначения нет.
конкретное применение RTOS (HRT) это всегда заточка, я писал уже что для таких применений планирование просчитывается вручную потом применяется. (под "вручную" здесь понимается "зарание").Но согласитесь коллеги, это же не общий случай - это конкретная индивидуальная заточка
2Serge:
Это бесспорно... Но я привык таки сначала понимать полностью происходяще (хотя бы на этом экране) , а потом уже делать нечто.
Метод тыка - это не очень мое искусство... Да и глаз дурной...
Честное слово, пару месяцев, это не очень большой срок для такового... Ну не профессиональный программист я (ну разве что AVR-ки), не идет оно у меня так быстро. Тем более, что пришлось таки еще и Forth познать (были свои причины).
Так что, если кому интересно, могу свое понимание подробно изложить в соответствующем топике. Ибо с разговорчивостью у фортеров - как-то не очень
Не, ну и до наглости дело дойдет, куда оно денется.... Не, не завтра...
2Ghost:
Да оба дестопа, вообще-то. Как-то уже не очень ДОС-варианты продаются... Все уже избалованы дружественным интерфейсом
Да, захочется, в процессе резки разобраться и в файлах заказов, может посчитать чего, может отчет написать, или описание каких-нибудь проблем передать по смене...
Т.е., это все процессы не связанные напрямую с задачей
А где одна-две, там и много.... 21-й век на дворе.
А чем я отличаюсь?
Да тем, что если, к примеру, при копировании файла в KFAR, он у меня вдруг "пропал" (он же не занимается рисованием в процессе копирования), то я не буду запускать его еще сотню раз и повторять содеянное
Наконец у меня хватит ума и в CPU заглянуть.
((если совсем честно, то именно KFAR, и именно второй раз, и именно по этой причине - уже запускал))
А на разумность оператора из Урюпинска я профессинально рассчитывать просто не имею права, хотя и знаю, что по настоящему тупых не так уж и много...
Про "вручную", и много изохронов - пощупать надо, подумать, попроверять. Может существуют варианты не настолько навороченные, как в продвинутых осях, но зато "автоматические"...
Ну мало ли... В смысле, автоматические - в плане оси. А конкретные цифры уставок на каждый изохрон - это просто предмет разработки системы.
Да, и я совершенно согласен с автором по приведенной Вами ссылки RemarksOnTheMargins: взамодействия потоков, их самоблокировки, и т.п. - это вообще не дело оси, а разработчика системы.
Головой думать надо, и понимать происходящее, а не на некоторые механизмы (типа инверсии приоритетов) в оси рассчитывать.
Глупости все это, наверное
Это бесспорно... Но я привык таки сначала понимать полностью происходяще (хотя бы на этом экране) , а потом уже делать нечто.
Метод тыка - это не очень мое искусство... Да и глаз дурной...
Честное слово, пару месяцев, это не очень большой срок для такового... Ну не профессиональный программист я (ну разве что AVR-ки), не идет оно у меня так быстро. Тем более, что пришлось таки еще и Forth познать (были свои причины).
Так что, если кому интересно, могу свое понимание подробно изложить в соответствующем топике. Ибо с разговорчивостью у фортеров - как-то не очень
Не, ну и до наглости дело дойдет, куда оно денется.... Не, не завтра...
2Ghost:
Да оба дестопа, вообще-то. Как-то уже не очень ДОС-варианты продаются... Все уже избалованы дружественным интерфейсом
Да, захочется, в процессе резки разобраться и в файлах заказов, может посчитать чего, может отчет написать, или описание каких-нибудь проблем передать по смене...
Т.е., это все процессы не связанные напрямую с задачей
А где одна-две, там и много.... 21-й век на дворе.
А чем я отличаюсь?
Да тем, что если, к примеру, при копировании файла в KFAR, он у меня вдруг "пропал" (он же не занимается рисованием в процессе копирования), то я не буду запускать его еще сотню раз и повторять содеянное
Наконец у меня хватит ума и в CPU заглянуть.
((если совсем честно, то именно KFAR, и именно второй раз, и именно по этой причине - уже запускал))
А на разумность оператора из Урюпинска я профессинально рассчитывать просто не имею права, хотя и знаю, что по настоящему тупых не так уж и много...
Про "вручную", и много изохронов - пощупать надо, подумать, попроверять. Может существуют варианты не настолько навороченные, как в продвинутых осях, но зато "автоматические"...
Ну мало ли... В смысле, автоматические - в плане оси. А конкретные цифры уставок на каждый изохрон - это просто предмет разработки системы.
Да, и я совершенно согласен с автором по приведенной Вами ссылки RemarksOnTheMargins: взамодействия потоков, их самоблокировки, и т.п. - это вообще не дело оси, а разработчика системы.
Головой думать надо, и понимать происходящее, а не на некоторые механизмы (типа инверсии приоритетов) в оси рассчитывать.
Глупости все это, наверное
Galkov
Насчет ехидности моего замечания - ничего ехидного. Просто за 5 лет людей рассуждающих: "как бы было зашибись, если бы все было зашибись" было очень много, людей предлагавших решения было меньше, а вот людей бравшихся за реализацию было совсем чуть-чуть, а тех кто реализовал что-либо совсем "кот наплакал".
Я согласен с тем что проблемы есть и они требуют решения, но:
1) Люди работают не за деньги, соответственно "пинать" их по какому либо поводу не имеет смысла.
2) Вытекает из п.1 - каждый реализует, то что считает интересным и нужным для себя, как справедливо заметил Сергей.
Если ты готов взяться за реализацию того что описываешь, то возможно тебе даже будут способствовать в этом, но если это только мысли вслух и "я укажу вам верную дорогу слепые котята" то ничего кроме раздражения у людей это вызвать не может, в лучшем случае будут игнорировать. Никто не считает тебя глупым и непонимающим, но согласись чтобы твое мнение было веским нужно еще что-нибудь кроме обозначения его в текстовом виде на форуме - должно быть то что можно "пощупать".
Сергей когда начал работать четко сказал, что он собирается делать и взялся за дело. За что ему большое спасибо. Если ты пойдешь тем же путем, то сложностей не возникнет, если нет... ну, думаю я уже достаточно написал.
Насчет ехидности моего замечания - ничего ехидного. Просто за 5 лет людей рассуждающих: "как бы было зашибись, если бы все было зашибись" было очень много, людей предлагавших решения было меньше, а вот людей бравшихся за реализацию было совсем чуть-чуть, а тех кто реализовал что-либо совсем "кот наплакал".
Я согласен с тем что проблемы есть и они требуют решения, но:
1) Люди работают не за деньги, соответственно "пинать" их по какому либо поводу не имеет смысла.
2) Вытекает из п.1 - каждый реализует, то что считает интересным и нужным для себя, как справедливо заметил Сергей.
Если ты готов взяться за реализацию того что описываешь, то возможно тебе даже будут способствовать в этом, но если это только мысли вслух и "я укажу вам верную дорогу слепые котята" то ничего кроме раздражения у людей это вызвать не может, в лучшем случае будут игнорировать. Никто не считает тебя глупым и непонимающим, но согласись чтобы твое мнение было веским нужно еще что-нибудь кроме обозначения его в текстовом виде на форуме - должно быть то что можно "пощупать".
Сергей когда начал работать четко сказал, что он собирается делать и взялся за дело. За что ему большое спасибо. Если ты пойдешь тем же путем, то сложностей не возникнет, если нет... ну, думаю я уже достаточно написал.
2Galkov
Если есть внешнее устройство, то должен быть и драйвер для него. Твоё внешнее устройство подключается скорее всего к параллельному порту, а если это так, то твоё устройство всегда может генерировать прерывание от параллельного порта, хоть тыщу раз в секунду. Чтобы обработать прерывание придётся написать драйвер, но если твоё устройство только принимает данные, то это больше похоже на драйвер принтера (данные выдаются и стробируются драйвером и квитируются устройством). Если ты напишешь драйвер параллельного порта (принтера), который принимает от приложения большой кусок данных, а потом побайтно выдаёт через параллельный порт, тебе будут только благодарны. А если твоё устройство имеет более хитрый протокол обмена, то придётся писать более специфичный драйвер, только для себя. Но принцип тот же, так что заодно и драйвер принтера можешь состряпать
Если есть внешнее устройство, то должен быть и драйвер для него. Твоё внешнее устройство подключается скорее всего к параллельному порту, а если это так, то твоё устройство всегда может генерировать прерывание от параллельного порта, хоть тыщу раз в секунду. Чтобы обработать прерывание придётся написать драйвер, но если твоё устройство только принимает данные, то это больше похоже на драйвер принтера (данные выдаются и стробируются драйвером и квитируются устройством). Если ты напишешь драйвер параллельного порта (принтера), который принимает от приложения большой кусок данных, а потом побайтно выдаёт через параллельный порт, тебе будут только благодарны. А если твоё устройство имеет более хитрый протокол обмена, то придётся писать более специфичный драйвер, только для себя. Но принцип тот же, так что заодно и драйвер принтера можешь состряпать
tsdima, если ты помнишь благодатные времена 98-й, то нафиг никакие драйверы не нужны были для обращения к портам. Работала бы она еще, до сих пор на ней сидел бы... Посмотри коды IoPorts.pas - делов-то.
И в KoOS драйверы тоже не нужны для обращения к портам, вроде
И это есть очень хорошо, между прочим
Ибо под XP, у меня среднее время обмена с портом около 5 мксек. А цикл ISA меньше микросекунды, вообще-то...
Да, именно на ём (LPT) у меня камень и сидит. Но это больше от отсутствия образованности.
Все одно придется в USB врезаться рано или поздно
Правда сидит очень удачно: двунаправленный режим в LPT (т.е., не очень уже и LPT), по-байтный обмен с камнем, у камня на шине данных целиком PortB, на котором же и линии егойного программирования.
В общем, "брюки могут превратиться"... даже и без легкого движения руки
Получилась простенькая многофункциональная карта (вообще-то у меня сегодня в ней пока всего 3 функциональности: TWI для вышеупомянутой системы, программатор InCircuitProgramming для моей периферии, и некий "драйвер" для отладки на мегах). Все это дело (8-я mega + несколько резисторов/диодов) спокойно умешается в корпусе DB-25 (прямо тот, который в комп и втыкается)
Функциональности остальных ног камня - для меня так выше крыши... Там и АЦП 8 входов (т.е., проблем с принятием и буферизацией 10кГц-ого аналогового сигнала у меня вообще никаких), COM, I2C (у них это правда это называется TwoWireInterface), не считая просто цифровых входов/выходов...
Вот по последнему все мои "думатели" меж собой и общаются.
Опять же, не потому, что я его считаю самым продвинутым, а потому-что он уже есть встроенный, "сеть" многомастерная даже, 500 кбит/сек мне вполне хватает, из дополнительных деталей для создания "сети" - по ферритовому колечку на линию для "гальваноразвязки" по высоким частотам
Т.е, у меня настолько все дешево и сердито, что страшное слово Драйвер - даже и вспоминать не очень хочется
Ты же помнишь, что является наилучшим средством от перхоти.....
Хм... Прерывания....
Если помнишь, в нашей VICX.sys такой функциональности просто нет.
Поэтому я и обхожусь без этого.
И, сказать честно, не очень пока (опять - дефицит образования) представляю, какому INT-у в защищенном режиме соответствует IRQ7 (или 9 - не помню точно, сейчас дома на буке LPT уже отсутствует напрочь)
Есть, конечно, идеи расширения функциональности, при использовании такового...
tsdima, но ведь в KoOS сесть на INT - тоже ведь драйвер не нужен
А вот консультация коллег НУЖНА была бы, как оно работает, синхронно, или асинхронно
В смысле: вектор int-а на 0-м кольце сразу (асинхронно) передает управление нужному потоку, или откладывает сие важное действо до времени срабатывания карусели (синхронно)
P.S. если я чего-то не совсем точно (или совсем не точно) понимаю - буду благодарен, если коллеги меня поправят.
Ну и прошу прощения за некоторый offtop....
((типа: открою кодекс на любой странице, и не могу - читаю до конца))
И в KoOS драйверы тоже не нужны для обращения к портам, вроде
И это есть очень хорошо, между прочим
Ибо под XP, у меня среднее время обмена с портом около 5 мксек. А цикл ISA меньше микросекунды, вообще-то...
Да, именно на ём (LPT) у меня камень и сидит. Но это больше от отсутствия образованности.
Все одно придется в USB врезаться рано или поздно
Правда сидит очень удачно: двунаправленный режим в LPT (т.е., не очень уже и LPT), по-байтный обмен с камнем, у камня на шине данных целиком PortB, на котором же и линии егойного программирования.
В общем, "брюки могут превратиться"... даже и без легкого движения руки
Получилась простенькая многофункциональная карта (вообще-то у меня сегодня в ней пока всего 3 функциональности: TWI для вышеупомянутой системы, программатор InCircuitProgramming для моей периферии, и некий "драйвер" для отладки на мегах). Все это дело (8-я mega + несколько резисторов/диодов) спокойно умешается в корпусе DB-25 (прямо тот, который в комп и втыкается)
Функциональности остальных ног камня - для меня так выше крыши... Там и АЦП 8 входов (т.е., проблем с принятием и буферизацией 10кГц-ого аналогового сигнала у меня вообще никаких), COM, I2C (у них это правда это называется TwoWireInterface), не считая просто цифровых входов/выходов...
Вот по последнему все мои "думатели" меж собой и общаются.
Опять же, не потому, что я его считаю самым продвинутым, а потому-что он уже есть встроенный, "сеть" многомастерная даже, 500 кбит/сек мне вполне хватает, из дополнительных деталей для создания "сети" - по ферритовому колечку на линию для "гальваноразвязки" по высоким частотам
Т.е, у меня настолько все дешево и сердито, что страшное слово Драйвер - даже и вспоминать не очень хочется
Ты же помнишь, что является наилучшим средством от перхоти.....
Хм... Прерывания....
Если помнишь, в нашей VICX.sys такой функциональности просто нет.
Поэтому я и обхожусь без этого.
И, сказать честно, не очень пока (опять - дефицит образования) представляю, какому INT-у в защищенном режиме соответствует IRQ7 (или 9 - не помню точно, сейчас дома на буке LPT уже отсутствует напрочь)
Есть, конечно, идеи расширения функциональности, при использовании такового...
tsdima, но ведь в KoOS сесть на INT - тоже ведь драйвер не нужен
А вот консультация коллег НУЖНА была бы, как оно работает, синхронно, или асинхронно
В смысле: вектор int-а на 0-м кольце сразу (асинхронно) передает управление нужному потоку, или откладывает сие важное действо до времени срабатывания карусели (синхронно)
P.S. если я чего-то не совсем точно (или совсем не точно) понимаю - буду благодарен, если коллеги меня поправят.
Ну и прошу прощения за некоторый offtop....
((типа: открою кодекс на любой странице, и не могу - читаю до конца))
Ну, это как товарищи ядростроители настроят.Galkov wrote:не очень пока (опять - дефицит образования) представляю, какому INT-у в защищенном режиме соответствует IRQ7
Насколько я понимаю, драйвер может работать внутри ядра не зависимо от того, какой процесс является текущим. После того, как твоё приложение передаст все данные (от начала и до конца) драйверу и он сохранит их в "ядрёной" памяти, ему (драйверу) уже будет по барабану, какой процесс выполнялся в тот момент, когда возникло прерывание (т.е. адресное пространство какого процесса лежит ниже границы 2Гб), т.к. сам драйвер не обращается к какому-либо процессу, а работает сам по себе. Как максимум, он может установить какой-нибудь семафор/мьютекс, которого, например, ждёт твоё приложение. А вот когда ОС даст поработать твоему приложению, тогда-то оно и обраружит это событие, и отреагирует соответственно. Т.е. драйвер работает по принципу: его попросили - он сделал, и поставил галочку. А сам он никуда кроме ядра не обращается.Galkov wrote:А вот консультация коллег НУЖНА была бы, как оно работает, синхронно, или асинхронно
В смысле: вектор int-а на 0-м кольце сразу (асинхронно) передает управление нужному потоку, или откладывает сие важное действо до времени срабатывания карусели (синхронно)
Все, этот вопрос снят.... По ассоциациям писал (во пень), перечитывание Руководящих Технических Материалов сняло все вопросы.
Драйвер - ну да, можно, но это уже особо тонкое извращение.
Насколько я понял, сидя на прерывании он может бесстыдно украсть время у любого потока, хоть сверх-изохронного.
В нем-то и можно порушить по-дурости все ядро вообще, и всю концепцию "rt-планирования" в частности.
Мне как-то понятнее использовать старшие 16 бит маски событий.
Если действительно перехватывать вектор драйвером, тогда (видимо) придется и с 59-м общаться - да видал я его в гробу в белых тапках.
Драйвер - ну да, можно, но это уже особо тонкое извращение.
Насколько я понял, сидя на прерывании он может бесстыдно украсть время у любого потока, хоть сверх-изохронного.
В нем-то и можно порушить по-дурости все ядро вообще, и всю концепцию "rt-планирования" в частности.
Мне как-то понятнее использовать старшие 16 бит маски событий.
Если действительно перехватывать вектор драйвером, тогда (видимо) придется и с 59-м общаться - да видал я его в гробу в белых тапках.
Last edited by Galkov on Mon Feb 09, 2009 9:55 pm, edited 1 time in total.
2Ghost
Коллега, Вы не так давно намекали, что "с гарантиями" поток получает не 10 мсек, а примерно половину...
Не могли бы Вы подробнее остановиться на этом вопросе
открыть глаза, так сказать
Коллега, Вы не так давно намекали, что "с гарантиями" поток получает не 10 мсек, а примерно половину...
Не могли бы Вы подробнее остановиться на этом вопросе
открыть глаза, так сказать
Who is online
Users browsing this forum: No registered users and 7 guests