在 Kext 中链接 Dylib？

我为 OS X 编写了一个 kext，它使用 (IOKit) libusb 和 jpeglib 实现了基于 USB 的帧缓冲区。这两个都是 dylib，由于某种原因，它们无法在 XCode 中正确链接，并且操作系统在尝试加载 kext 时不会解析依赖关系。

整个事情的背景是三星制造了一款可以充当第二个显示器的液晶相框；唯一的问题是它不是 DisplayLink 或任何其他已知的协议——仅限 Windows 的驱动程序会输出自定义标头，并且每个帧都被编码为 JPEG 并发送到设备。我的实现在 OS X 上实现了这一点，但我使用了 libusb，因为它是一个帧缓冲区设备，需要在启动时加载——想要更多地处理驱动显示器而不是热插拔检测和 IOKit 的 USB 设备要求。

谢谢你的帮助！你们太棒了。

恐怕 kext 本身并不是严格动态链接的（它们在运行时加载，但它们的结构是静态的），并且除非进行一些英勇的自定义链接器/加载器工作，否则您将无法将 dylib 加载到内核空间中。

据我所知，libusb的目的是编写USB驱动程序user空间。因此，我不清楚为什么你首先要构建一个 kext（它将在内核空间中运行）。设备中是否有某些元素无法使用 libusb 从用户空间驱动？如果是这样，请尝试仅为该组件创建 kext，并将驱动程序的其余部分放入用户空间守护程序中。

如果 libusb 和仅内核组件之间的拆分不起作用，则需要在 kext 中使用内核空间 IOKit USB API。您可能会找到一个静态编译的 JPEG 库，并且可以在 kext 中使用（尽管没有完整的 libc 将是一个问题），但我强烈怀疑您实际上并不想这样做 - JPEG（de ）压缩似乎应该在用户空间中完成。

我的印象是您根本不需要构建自己的 kext - 创建一个命令行（或 GUI）应用程序，将 libusb 和 jpeglib 链接到它，并在用户空间中完成这一切。如果您希望它进入后台，请使用常用的 fork() 方法来守护进程，使用管道、套接字或其他 IPC 与驱动程序的使用者进行通信。如果您可以以某种方式避免编写一行内核代码，我强烈建议您坚持使用用户空间。调试内核代码是一件非常痛苦的事情，驱动程序越复杂，情况就越糟糕（我认为 JPEG 解/压缩很复杂）。

像往常一样，更多信息会很有用，特别是我提到的部分。