Ядро против драйвера устройства пользовательского пространства

Question

Мне нужно разработать драйвер аудиоустройства для System Audio Capture (на основе Soundflower).
Но вскоре появилась проблема: кажется, что стек IOAudioFamily устарел в OSX 10.10 и более поздних версиях.
Просматривая файлы заголовков IOAudioDevice и IOAudioEngine, кажется, что Apple рекомендует использовать API <CoreAudio/AudioServerPlugIn.h>, который работает в пользовательском пространстве. Но я не могу найти много информации об этой теме драйверов устройств пользовательского пространства. Кажется, что единственным ресурсом является Apple, предоставляющая образцы устройств от https://developer.apple.com/library/prerelease/content/samplecode/AudioDriverExamples/Introduction/Intro.html
Просматривая примеры, я нахожу, что его намного сложнее и труднее разрабатывать драйвер пользовательского пространства вместо ядра ядра ввода-вывода.
Итак возникает вопрос, что должно мотивировать разработку драйвера устройства в пользовательском пространстве вместо пространства ядра?

Answer 1

Существует большая книга на эту тему, можно бесплатно на сайте здесь:

http://free-electrons.com/doc/books/ldd3.pdf

См стр 37 для резюме, почему вам может понадобиться драйвер пользовательского пространства, скопированного здесь для удобства:

преимущества пользовательского пространства водителей:

• полная библиотека C могут быть связаны Драйвер может выполнять множество экзотических задач, не прибегая к внешним программам (утилита программ, реализующих политики использования, которые обычно распространяются вместе с самим драйвером).
• Программист может запускать обычный отладчик по коду драйвера, не выполняя искажения для отладки запущенного ядра.
• Если драйвер пользовательского пространства висит, вы можете просто его убить. Проблемы с драйвером вряд ли повесят всю систему, если только аппаратное обеспечение не будет работать.
• Пользовательская память заменяется, в отличие от памяти ядра. Нечасто используемое устройство с огромным драйвером не будет занимать ОЗУ, которое могли бы использовать другие программы , за исключением случаев, когда он действительно используется.
• Хорошо спроектированная программа драйверов может по-прежнему, подобно драйверам ядра, разрешать одновременный доступ к устройству.
• Если вы должны написать драйвер с закрытым исходным кодом, опция «пространство пользователя» упрощает вам избегать неоднозначных ситуаций лицензирования и проблем с изменением интерфейсов ядра.

Answer 2

Пример «SimpleAudioDriver» несколько неназванный. Он демонстрирует почти все функции API. Это удобно в качестве ссылки, если вам действительно нужно использовать эти функции. Он также структурирован таким образом, что это может быть немного сложнее, чем необходимо.

Для виртуального устройства NullAudioDriver, вероятно, является намного лучшей базой, и гораздо проще понять (файл с одним источником, если я правильно помню). SimpleAudioDriver более полезен для решения таких проблем, как hotplugging, несколько экземпляров идентичных устройств и т. Д.

устарел, как вы говорите, и был с OS X 10.10. Ожидайте, что он уйдет в конце концов, поэтому, если вы построите свой драйвер вместе с ним, вам, вероятно, придется переписать его раньше, чем если бы вы создали основанный на Core Audio Server плагин.

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

(FWIW, я погружен как ядра и в пользовательском пространстве OS X драйвера аудио, и я провожу много времени, работая на кекстах.)