системные сообщения
вообще то таких функций нет...
а какие ещё обращения к оси (sysenter что ли?)
а дос и линух через прерывания обращаются .
ещё можно через шлюзы . это механизмы сообщений .
а формат : дос через регистры и иногда буфер в памяти .
выньдос через стек .
вот меня и интересует что лучше в смысле быстродействия .
разницы нет через что ты вызываешь сервисы всё равно в результате их вызова произойдёт переход в режим нулевого кольца
в досе совсем прерывания обрабатываются быстрее потому в нём нет колец защиты
koderAlex, ты спрашиваешь о передаче параметров при обращении к системному сервису?
для контроллера дма тип F не используешь ?
я обдумываю такой вариант : приложение (без разницы - драйвер или нет) посылает запрос на операцию в лбщем виде : лба адрес , выровненный логический адрес , размер буфера .
система пересылает запрос девайс менеджеру если у приложения есть права доступа . девайс менеджер создаёт буфер и посылает запрос конкретному драйверу передавая ему физический адрес .
драйвер инит уст-во . по окончании передачи посылает сигнал девайс менеджеру . девайс менеджерпроверяет присутствие процесса запросившего обмен и если он ещё активен посылает запрос менеджеру оперативки на обмен страниц , иначе буфер убивается . это вариант для чтения данных .
для контроллера дма тип F не используешь ?
Для медленных устройств лучше использовать совместимый тип (ISA-compatible), а для быстрых, тех же дисков, UltraDMA-режимы.
система пересылает запрос девайс менеджеру если у приложения есть права доступа . девайс менеджер создаёт буфер и посылает запрос конкретному драйверу передавая ему физический адрес .
По-моему, все-таки должна быть разница между непосредственно управляющим устройством драйвером и инициатором запроса на работу с устройством (посторонним драйвером/приложением). Зачем постороннему драйверу/приложению оперировать физическим адресом буфера? Лучше пусть сам "родной" драйвер посредством ядра связывает логический адрес с физическим адресом буфера!
Часто драйверы используют одни и те же физические буферы для обслуживания запросов со стороны разных процессов! Поэтому при (преждевременном) завершении какого-то процесса лучше "убивать" не реальный физический буфер, а связанный с ним логический фрейм в адресном пространстве процесса как один из шагов уничтожения этого адресного пространства. Что касается взаимодействия, то ты описываешь практически стандартные шаги (если я, конечно, все правильно понял) за искючением того, что буфер при преждевременном завершении процесса не "убивается", а просто разблокируется системой.
8 мегов/сек - маловато . а скорость обмена определяется устройством а не дма контроллером .
По-моему, все-таки должна быть разница между непосредственно управляющим устройством драйвером и инициатором запроса на работу с устройством (посторонним драйвером/приложением). Зачем постороннему драйверу/приложению оперировать физическим адресом буфера? Лучше пусть сам "родной" драйвер посредством ядра связывает логический адрес с физическим адресом буфера!
я ж специально отметил что в запросе передаётся логический адрес . запрос передаётся через ядро , а уж оно знает какой физический адрес соответствует заданному логическому .
Часто драйверы используют одни и те же физические буферы для обслуживания запросов со стороны разных процессов! Поэтому при (преждевременном) завершении какого-то процесса лучше "убивать" не реальный физический буфер, а связанный с ним логический фрейм в адресном пространстве процесса как один из шагов уничтожения этого адресного пространства. Что касается взаимодействия, то ты описываешь практически стандартные шаги (если я, конечно, все правильно понял) за искючением того, что буфер при преждевременном завершении процесса не "убивается", а просто разблокируется системой.
не внимательно читаеш .повторюсь : буфер убивается в случае если процесс пославший запрос к моменту передачи буфера перестал существовать .
а буфера создаются в диспетчере драйверов который знает сколько потоков может обслужить драйвер . страницы буфера совмещаются в адресных пространствах драйвера и диспетчера .
А я не говорил, что скорость определяется DMA-контроллером! Но DMA может наложить свои ограничения на скорость передачи, тот же тип F имеет вполне конкретный предел, который для жестких дисков совсем не подходит! Кстати, у совместимого типа макс. скорость варьируется в пределах 1-2 мег/сек, но существует ряд устройств, которым этого вполне достаточно!
А что тогда такое "лба адрес"? Я думал, что ты так назвал физический адрес!
а буфера создаются в диспетчере драйверов который знает сколько потоков может обслужить драйвер . страницы буфера совмещаются в адресных пространствах драйвера и диспетчера .
Я все нормально понял! Повторяю, физические буферы (резервируемые для работы участки памяти) часто создаются драйверами на все время их работы и мапятся по запросу в адресные пространства разных процессов, а чтобы не возникало проблем с раздельным доступом к этому буферу, используется механизм блокировки буфера (для приложений непосредственно блокируется сам буфер, для драйверов проще использовать какой-нибудь синхронизирующий объект). Если процесс завершается, по каким-то причинам не разблокировав буфер, то это делает система в процессе "сборки мусора" за этим процессом. Таков примерный расклад... В каждом конкретном случае своя специфика. У меня, например, нет как такового диспетчера драйверов, а есть диспетчер (виртуальных) устройств, который не выполняет каких-то сверх интеллектуальных функций, а лишь отвечает за доставку параметров драйверу конкретного устройства и при опред. условиях выполняет блокировку устройства.
самый быстрый метод передачи инфы драйверу это METHOD_NEITHER, а если нужна защита METHOD_BUFFERED
встроенные в проц дма контроллеры не должны накладывать ограничения .
А что тогда такое "лба адрес"? Я думал, что ты так назвал физический адрес!
LBA . параметр запроса (у меня) . драйвером диска транслируется в номер кластера (к примеру). может игнорироваться другими драйверами .
Сразу бы так и сказал, что это конкретный пример передачи параметров для диска! Я бы тут про физический ардес и не теоретизировал! Другие драйверы будут требовать другие параметры, поэтому лучше обозначать их как-то абстрактно!