OSDev

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


Я имел в виду взять их за основу, использовать их логику, т.к. не на всё можно найти документацию. Естественно, переделывать придется многое. Хотя, конечно, во многих случая все равно будет проще прочитать, после чего - Ctrl+A и Shift+Del.

Отделено отсюда.

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

Можно возразить, что, дескать, ядро для своей работы при такой схеме монополизирует процессор и останавливает любую другую активность в системе, а это, дескать, приведёт к плохой реакции системы на "внешние раздражители" (прерывания) и к другим бедам. Но это не так. То, что код ядра работает непрерывно до своего полного выполнения, не означает автоматом, что он работает при запрещённых прерываниях: ничто не мешает, выполнив некоторую критическую часть обработки (которая по-любому должна выполняться при запрещённых прерываниях), разрешить прерывания -- вот и быстрая реакция системы на прерывания. Естественно, при этом требуется обеспечить синхронизацию доступа к общесистемным данным, но это уже другой вопрос, к тому же не шибко сложный даже на многопроцессорной системе (а на однопроцессорной и вовсе элементарный -- в отличие от "разруливания" проблем с потоками ядра). Ну а если не пихать в ядро "тяжёлые" и "долгоиграющие" драйверы вроде файловых систем и сетевых протоколов, а оформлять их задачами, отпадает и проблема со скоростью реакции системы с точки зрения пользователя: такие драйверы будут разделять процессорное время с обычными задачами. Собственно, из современных систем Винда, наконец, потихоньку начала идти по второму пути: из ядра изымаются различные драйверы, которые не являются там шибко необходимыми. В частности, почти весь код драйверов видюх перекочевал в режим пользователя (в частности, там выполняется компилятор шейдеров). Но сама эта идея отнюдь не нова; именно так было поставлено дело в RSX-11, а это ещё ранние 1970-е годы.

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

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

Поправка: драйверы режима пользователя. Есть драйверы режима ядра, для которых потоки не нужны (то, что в Винде часто используются ядерные потоки, ничуть этому не противоречит: во-первых, в Винде есть "левый" код, который без потоков жить не может просто потому, что его так реализовали, а драйверы вынуждены пользоваться этим кодом, а значит, и потоками; а во-вторых, программистам нередко банально лень думать, как разрулить дело без потоков). Ну а у драйверов режима пользователя есть определённый стандартный интерфейс с ядром. Работают они, как обычные задачи, а значит, могут пользоваться обычными функциями ВинАПИ, но есть и добавки именно для драйверов. Какие именно, надо изучать внимательно доку на Винду, а я этим не занимался. Знаю лишь, что эти добавки могут зависеть от вида драйвера. Например, пользовательская часть драйвера видюхи взаимодействует с пользовательской же частью ДиректХ, а значит, и интерфейс между ними строго определённый и не имеющий отношения к, скажем, интерфейсу между драйвером контроллера УСБ-хоста (который в ядре) и драйверами УСБ-устройств (которые рекомендуется делать в режиме пользователя).



А зря. Её стоило б изучить, хотя она и переусложнена. Причём в первую очередь WDM, а отнюдь не появившуюся в Висле WDF, поскольку последняя является лишь объектно-ориентированной надстройкой над первой, а значит, без понимания работы WDM невозможно понять работу WDF (хотя без знания WDM вполне можно научиться писать WDF-драйверы, ведь там достаточно знать, как и что делать, даже не понимая, что происходит в недрах системы).

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

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

1. Задача выдаёт системе запрос "начать ввод-вывод", указывая устройство, вид операции (чтение, запись и т.д.), адрес и размер буфера ввода-вывода и т.п. информацию.

2. Менеджер ввода-вывода выполняет общую часть работы по запуску ввода-вывода: проверяет положение буфера, фиксирует его страницы в памяти и т.д. и т.п. Задача в это время, понятное дело, стоит, ведь система обрабатывает её запрос (и может вернуть ошибку, если какие-то параметры будут неправильными).

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

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

5. Менеджер ввода-вывода на этом завершил обработку запроса задачи на запуск ввода-вывода, этому задача вновь получает управление и может выполняться дальше. Заметим, что параллельно выполняется (ну или ожидает в очереди) выданный ей запрос ввода-вывода. Таким образом, дальнейший ход работы задачи и ввода-вывода между собой не связаны, т.е. они выполняются асинхронно.

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

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

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

Спасибо, вроде понял. Получается так: драйвера режима ядра выполняются не как системные потоки, а как просто код, занимающий процессор на все время своей работы?

Именно так. Можно сказать, работают в контексте ядра, а не конкретного потока. Конкретный поток нужен лишь при запуске операции (когда идёт проверка параметров, привязанных к потоку -- например, адреса и длины буфера ввода-вывода) и при её завершении (ведь уведомить о завершении надо конкретный поток, а не абы какой). Всё остальное время драйвер работает сам по себе, пользовательский код -- сам по себе.

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