我为 OS X 编写了一个 kext，它使用 (IOKit) libusb 和 jpeglib 实现了一个基于 USB 的帧缓冲区。这两个都是 dylib，由于某种原因，它们无法在 XCode 中正确链接，并且操作系统在尝试加载 kext 时不会解决依赖关系。
整个事情的背景是三星制造了一个液晶相框，可以作为第二个显示器；唯一的问题是它不是 DisplayLink 或任何其他已知协议——仅限 Windows 的驱动程序会输出一个自定义标头，并且每个帧都被编码为 JPEG 并发送到设备。我的实现是为 OS X 做的，但我使用了 libusb，因为它是一个帧缓冲设备，需要在启动时加载——想要更多地处理驱动显示器而不是热插拔检测和 IOKit 的 USB 设备要求。
谢谢你的帮助！你们真棒。
恐怕 kexts 本身并没有严格动态链接（它们在运行时加载，但它们的结构是静态的）并且除非进行一些英勇的自定义链接器/加载器工作，否则您将无法将 dylib 加载到内核空间中。
据我所知，libusb 的重点是在用户空间编写 USB 驱动程序。因此，我不清楚你为什么首先要构建一个 kext（它将在内核空间中运行）。是否有一些设备元素不能使用 libusb 从用户空间驱动？如果是这样，请尝试仅为该组件创建一个 kext，并将驱动程序的其余部分放在用户空间守护程序中。
如果在 libusb 和仅内核组件之间拆分不起作用，则需要在 kext 中使用内核空间 IOKit USB API。您可能会找到一个静态编译的 JPEG 库，并且可以在 kext 中使用（尽管没有完整的 libc 将是一个问题），但我强烈怀疑您实际上并不想这样做 - JPEG（de ）压缩似乎应该在用户空间中完成。
我的印象是您根本不需要处理构建自己的 kext - 创建一个命令行（或 GUI）应用程序，将 libusb 和 jpeglib 链接到它，然后在用户空间中完成所有操作。如果您希望它进入后台，请使用通常的 fork() 方法来守护您的进程，使用管道、套接字或其他 IPC 与驱动程序的使用者进行通信。如果您能以某种方式避免编写单行内核代码，我强烈建议您坚持使用用户空间。调试内核代码是一个巨大的痛苦，驱动程序越复杂，它变得越糟糕（我认为 JPEG 解/压缩很复杂）。
像往常一样，更多信息会很有用，尤其是关于我提到的部分。