Я думаю, что ответ на ваш вопрос сводится к тому, присущего противоречия в том, что вы спрашиваете:
Все виртуальные драйверы устройств, которые не контролируют любые аппаратные устройства, кажется, совпадают по IOResources
против
Что я не underst и как ваш драйвер получает вызов от системы, так как система не знает, какое устройство вы контролируете?
Либо есть реальное устройство для управления, либо нет, когда это виртуальный драйвер устройства. В случае с реальным драйвером поставщик будет областью или объектом устройства, таким как IOPCIDevice, IOUSBDevice/IOUSBHostDevice, IOUSBInterface/IOUSBHostInterface и т. Д. Поставщик вашего драйвера - это устройство, которым управляет ваш драйвер.
С другой стороны, каждый драйвер рекламирует, какие услуги он предоставляет операционной системе, другим процессам kexts или пользовательскому пространству. Это сигнализируется главным образом типом (супер) класса основного объекта вашего драйвера или любых создаваемых им объектов-нубов и регистрируется с помощью регистра ввода-вывода. Клиенты, которые понимают эти интерфейсы, в свою очередь будут соответствовать объектам драйвера в качестве их поставщиков.
Ваш пример аудиодрайверов на самом деле демонстрирует 2 способа, которыми это может работать. Аудиоподсистема OS X в основном работает в пользовательском пространстве - в частности, coreaudiod. Так как OS X 10.8, в том числе и сами драйверы аудиоустройств, хотя устаревший API ядра IOAudioDevice/IOAudioEngine все еще существует, и Apple отправляет драйверы, которые используют его как OS X 10.11.
В исходном/звуковом драйвере драйвера ваш драйвер будет реализовывать подклассы IOAudioDevice и IOAudioEngine и, возможно, некоторые другие классы. Когда экземпляры этих классов зарегистрированы в реестре ввода-вывода, Core Audio Daemon обнаруживает это через механизм сопоставления служб и создает пользовательские клиенты для связи с этими объектами ядра. Core Audio будет соответствовать любым объектам, которые соответствуют интерфейсу IOAudioEngine. Думаю, это вопрос, который вы задаете.
В современном аудио-драйвере Info.plist пакета аудиосервера HAL содержит набор подходящих для ввода/вывода наборов. Он может напрямую соответствовать классу поставщика, предоставляемому системой, например, IOUSBInterface, если устройство можно управлять напрямую. Для устройства PCI вам, скорее всего, понадобится настраиваемый kext для обработки памяти и обработки прерываний. Этот kext, скорее всего, просто подкласс IOService, не более конкретный, и предоставить свой собственный пользовательский класс клиента. Затем плагин HAL сопоставляется с именем конкретного имени класса kext и открывает соединение с ним с пользовательским классом клиентских пользователей.
Я надеюсь, что ответит на ваш вопрос?
Привет, мне нужно написать звуковой сервер HAL-плагин для выполнения некоторой обработки звука, прежде чем выпустить его на USB-устройство. Вы упомянули, что плагин может напрямую соответствовать IOUSBInterface, однако до сих пор мне удалось создать новые виртуальные аудиоустройства в плагине, в то время как я хочу управлять существующим. Я вижу, что эта система подключает драйвер AppleUSBAudio к моему устройству, но я не могу найти способ контролировать его в своем плагине. Единственное решение, которое я нашел, - это каким-то образом заблокировать AppleUSBAudio от присоединения и сделать всю работу USB самостоятельно. Интересно, есть ли другой, возможно, более простой способ сделать это. – prazuber
@prazuber Я не уверен, что плагин HAL - это способ пойти на это. Обработка звука обычно выполняется в [Audio Units] (https://developer.apple.com/library/content/documentation/MusicAudio/Conceptual/AudioUnitProgrammingGuide/Introduction/Introduction.html). Другой вариант - реализовать USB Audio Plugin Kext, [см. Этот пример кода] (https://developer.apple.com/library/content/samplecode/SampleUSBAudioPlugin/Introduction/Intro.html#//apple_ref/doc/uid/DTS10003471). В любом случае, это не по теме для этого вопроса, поэтому, пожалуйста, откройте новый вопрос. Используйте теги «device-driver» + osx, чтобы я это увидел. – pmdj
Аудиоустройство не является вариантом, потому что мне нужно обработать весь звук, который перенаправляется на устройство, безусловно. USB Audio Plugin Kext хорош, но я не могу выполнять обработку в ядре из-за зависимостей библиотеки. В любом случае, спасибо за ваш ответ, я надеялся, что есть способ как-то сделать это через плагин HAL самостоятельно, но теперь я вижу, что единственным вариантом является плагин HAL + собственный драйвер USB, который я буду использовать из плагина , Eh, действительно очень хотелось бы избежать записи USB-файлов ... – prazuber