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