Боюсь, что кексы не являются строго динамически связанными (они загружаются во время выполнения, но их структура статична), и, если вам не нужно какое-то героическое пользовательское компоновщик / загрузчик, вы не получите dylib для загрузки в пространство ядра.
Насколько я знаю, цель libusb - писать драйверы USB в пользовательском пространстве.Поэтому мне непонятно, почему вы сначала создаете kext (который будет работать в пространстве ядра).Есть ли какой-то элемент устройства, который не может быть запущен из пользовательского пространства с помощью libusb?Если это так, попробуйте сделать kext только для этого компонента и поместить оставшуюся часть драйвера в демон пользовательского пространства.
Если разделение между libusb и компонентом, работающим только с ядром, не будет работать, вам потребуетсяиспользуйте ядро IOKit USB API в вашем kext.Вероятно, вы можете найти библиотеку JPEG, которая будет компилироваться статически и которая может быть использована в kext (хотя проблема не в наличии полной библиотеки libc), но я сильно подозреваю, что вы на самом деле этого не хотите - JPEG (де) сжатие выглядит так, как будто оно должно выполняться в пространстве пользователя.
У меня сложилось впечатление, что вам вообще не нужно заниматься созданием собственного kext - создайте приложение для командной строки (или GUI), ссылкуlibusb и jpeglib и делайте все это в пространстве пользователя.Если вы хотите, чтобы он ушел в фоновый режим, используйте обычный метод fork (), чтобы демонизировать ваш процесс, используя канал, сокет или другой IPC для связи с потребителями вашего драйвера.Если вы можете как-то избежать написания одной строки кода ядра, я настоятельно рекомендую придерживаться пользовательского пространства.Отладка кода ядра - огромная проблема, и чем сложнее драйвер, тем хуже он становится (я бы посчитал, что сжатие / сжатие JPEG является сложным).
Как обычно, будет полезна дополнительная информация, особенно очасти, которые я упоминаю.