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

Грубо говоря, у меня альтернативы:
а) собирать свой драйвер sound-заглушку для честного трассирования событий в infinity
б) следовать своему вышеизложенному плану, и заниматься исследованиями супер-хитрых и сверх-запутанных обработчиков IRQ

Поскольку коды из event я уже наизусть знаю, мне даже и тестовый редактор для них не очень нужен ...
Типа, идешь курить на балкон, и думаешь про себя: "а нафига в sys_sendwindowmsg нужна магическая комбинация pushfd/popfd..."

Не успел отписаться. Заработало.

Уффф

Как разборка полетов (в качестве самокритики):
1) Последняя ошибка - следствие тупого копипастинга (сколько раз зарекался, но лень берет свое) из 172-й строки. Такого добра и при "простом стиле" хватает. Если не не больше...
2) А вот в RemoveEventTo - соглашусь, стремление к оптимизации. Правильно - сначала полноценно удалить из списка, а потов врезать в другой. Наоборот - оптимальнее, но в одном случае (когда "другой" совпадает с "первым") - гробят списки напрочь.
Хотя, мог бы и сразу за это догадаться, а не под прессингом "все пропало, все на забор"

P.S. А то, что я по-первости напрочь упустил использование EVENT в infinity - за это и говорить нечего... Надо было просто "остудить моск", и всего делов

Galkov wrote:А тестовый пример для проверки правильности показаний show_error_parameters при debug_exception и отсутствии самого отладчика - как-то сразу в голову и не приходит...

Тестовый пример простой: В 0.7.5.0 выводит не то, что ожидалось, так что бага определённо была. В последнем ядре выдача нормальная, так что, по крайней мере, стало лучше Исправления в коде ещё не смотрел.

diamond wrote:Исправления в коде ещё не смотрел

Serge был немного шокирован, мне показалось.
И мне интересны и Ваши соображения, diamond, про "стиль", "понятность", и т.п..
Можно даже сказать, что я взял паузу на самообразование (сигналы в posix), в ожидании Ваших соображений

Galkov wrote:И еще, я пока вообще плохо себе представляю как работет dosbox (речь о нем ???), средства v86 вроде никуда и не экспортируется....

DOSBox - это полностью программная реализация эмулятора, без поддержки со стороны системы. В линейке WinNT (до Vista и если не учитывать x86-64), кстати, есть эмуляция dos-программ через v86-режим и работает она так криво, что лучше DOSBox Как-никак программы для DOS писались из расчёта на однозадачную среду и захватывают все ресурсы, что неприемлемо для многозадачной системы.
V86 в данный момент используется только для вызова функций BIOS через int 13h (дисковая подсистема). В принципе можно ещё добавить переключение банков в VESA 1.2 через int 10h, но поскольку тестить не на чем...

diamond wrote:DOSBox - это полностью программная реализация эмулятора, без поддержки со стороны системы

Сдуреть можно

diamond wrote:V86 в данный момент используется только для вызова функций BIOS через int 13h (дисковая подсистема). В принципе можно ещё добавить переключение банков в VESA 1.2 через int 10h, но поскольку тестить не на чем

Про 13-е, это я уже догадался.
Где-то здесь (где - не могу вспомнить) прочитал, что VESA 3.0 тоже через это дело идет... Тут вроде есть на чем тестировать.

Народ, у меня все-таки вопрос один без ответа остается....

Что означает фраза "Текущая реализация во время ожидания требует довольно "тяжёлых" операций переключения контекста" (это из описания f68:14) В чем "тяжесть-то"
Мне казалось, что это постоянное дергание CR3. Исходя из этого, и придумывал Wait_events

Но возможно, что это не более, чем мои фантазии. Ибо опыта кодинга под 0-м кольцом аж никакого.
ЕСЛИ я прав, то тогда надо думать и над другими "тяжелыми переключениями"
Например, в debugger_notify придуманный фокус не спасает, потому-что там два переключения. Сначала shed переключает контекст, без знания нужно ли это, а потом еще и в тестируемый слот переключаемся, только для проверки готовности
Подозреваю, что и в IPC примерно такая же история....
Wait_events может спасти только от первого переключения.
А от второго....
Ну может перед ожиданием дополнительно замэпить пользовательскую страничку с "мьютексом" куда-нибудь в системную область, поместивши этот логический адрес в wait_param...
Может вообще выделить это в отдельный функционал типа WaitUserMutex ....

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

diamond wrote:А это уже никакие не "2.56 секунд", а потенциально сколь угодно долгий срок. Особенно если учесть, что ждать придётся вовсе не до выхода из функции, а именно пока работающая с диском прога не перестанет выдавать запросы к 70-й (58-й) функции (потому что вероятность того, что прерывание таймера, обработчик которого и занимается переключением процессов, придёт ровно в момент между вызовами функций, довольно мала. А на то, чтобы в момент освобождения мьютекса и выхода из функции вызвать планировщик немедленно, интеллектуальности у Колибри сейчас не хватает. А переделать это не так уж и тривиально).

В принципе, мне уже понятно, как решать этот вопрос. В смысле - убрать "потенциально сколь угодно долгий срок".
Ну по сложнее это будет несколько, чем сегодняшний wait_mutex... Который сегодня оптимизируется до 4-х команд проца (12 байт кода).
Но ради вышеописанного, я готов наступить "на горло собственной песне"
Плюс к этому, есть еще скользкий вопрос - чего будет, если кто-то убьет поток, захвативший сегодняшний mutex...

Если коллеги посчитают таковое движение правильным, я могу предварительно описать "схему мероприятий", и, по согласии с этой "схемой" - сделать кодинг.

Galkov wrote:Если коллеги посчитают таковое движение правильным, я могу предварительно описать "схему мероприятий", и, по согласии с этой "схемой" - сделать кодинг.

Колибри не имеет плана развития как такового, так что можно делать всё в разумных пределах (переписывание на "что-нибудь посложнее, чем сегодняшний wait_mutex" в эти пределы входит, а переписывание ядра на Си таки нет).

Кто неправильно застегнул первую пуговицу, уже не застегнётся как следует. (c) Гёте
Дисклеймер: все дальнейшие высказывания являются а) моим личным мнением и б) неконструктивной критикой, так что если вы не любите неконструктивную критику и полагаете, что дадите ответ в стиле "и что же ты предлагаешь", то не читайте - этим сэкономите и ваши, и мои нервы.
Колибри в некоторой степени можно сравнить с деревянным домом. Дом неплохо смотрится снаружи и изнутри, внутри стоят столы, стулья, магнитофон, рация, на стенах висят картины, на видном месте лежат молоток, гвозди, пила, кисти, краски, прочие инструменты и инструкции по сбору своих стульев и картин. Дом достаточно прочный, сидя на стуле, можно смело чихать, не опасаясь того, что дом развалится. Жуков-древоточцев мало, и против них принимаются меры. Но если присмотреться, то обнаруживается куча странных вещей. Строители дома как такового умели держать в руках молоток и гвозди, но не карандаш и бумагу, так что чертежей постройки нет и никогда не было. В результате нет надёжного фундамента. Кое-где постройка держится на честном слове, если в определённых местах попрыгать, держа молоток под определённым углом, можно повиснуть в воздухе, а можно и развалить дом. Дом в принципе не предназначен для того, чтобы ходить по нему вдвоём - во-первых, шаги придётся делать строго по очереди, во-вторых, пока открывается журнал на почитать, магнитофон не может читать кассету, в-третьих, нет отдельных комнат, в которых можно было бы настроить всё под свой вкус, а вместо этого предлагается обустраивать весь дом, что будет видно любому гостю (и любой гость сможет всё переставить). Каждому объекту должна соответствовать картина. В доме есть место под 256 картин, большего количества быть не может, а если их меньше, то всё равно выделено 256 мест (причём первые два места специальные). Если нужно показать стул на двух картинах, то придётся отщеплять от него щепку и связывать картину с ней, и наоборот: если от стула отщепляется щепка, с ней связывается новая картина. Рация может связываться с разными адресатами, но даже если в доме ловится больше одной частоты, рация понимает только одну. Если рация настроена на приём, она не может принимать данные одновременно от нескольких адресатов. Рация не реагирует на приходящие волны, как можно было бы подумать, а с определёнными интервалами сканирует окружающее пространство, проверяя, не появилось ли новых данных (но сканирование может быть отложено, если в этот момент происходит много других дел). Средств для связи между разными объектами практически нет, максимум можно переложить журнал с одного стула или стола на другой (причём в процессе перекладывания журнала прочие действия останавливаются). Хотя открыта детальная схема сборки из брёвен и гвоздей, но разбираются в ней немногие, а никаких путеводителей по этой схеме (это, конечно, не схема небоскрёба, но всё равно весит довольно прилично) нет (чертежей, проясняющих, что вообще происходит, нет в принципе). Кое-где опорные брёвна положены откровенно криво (для опытного взгляда), кое-где забиты лишние гвозди. Временами делаются более или менее успешные попытки переложить часть досок так, чтобы они лежали более правильно, чаще дело ограничивается разговорами в стиле "а вот хорошо было бы, если кто-нибудь вот так вот переложил и добавил вот такие-то доски", инициируемых либо авторами картин, либо вообще сторонними посетителями, при том, что на стульях и картинах это либо вообще не сказывается, либо они чуть-чуть перекашиваются и их остаётся чуть-чуть поправить.
Вернёмся от метафор к реальности.
Почему до сих пор нет ATA48? Потому что это потребует значительных изменений в дисковой подсистеме и изменения всех вызовов hd_read, причём нетривиального изменения (вместо 32-битного входа понадобится 48-битный, а в один x86-регистр это уже не влезает).
Почему до сих пор нет USB? Отвлечёмся от вопросов программирования железа, очевидцы говорят, что это само по себе нетривиально, но допустим, что драйвера USB-хостов уже есть. И что с ними можно сделать? На plug-and-play ядро изначально не было рассчитано. Поддержка USB-клавиа