在 Kexts 中链接 Dylib?

本文介绍了在 Kexts 中链接 Dylib?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

限时送ChatGPT账号..

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

I've written a kext for OS X that implements a USB-based framebuffer using (IOKit) libusb and jpeglib. Both of those are dylibs, and for some reason they won't link properly in XCode, and the OS won't resolve the dependencies when it attempts to load the kext.

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

The background of this whole thing is that Samsung makes an LCD picture frame that can act as a second monitor; the only problem is that it's not DisplayLink or any other known protocol -- the Windows-only driver spits out a custom header and each frame is encoded as a JPEG and sent to the device. My implementation does that for OS X, but I used libusb since it's a framebuffer device and needs to be loaded at startup -- wanted to deal more with driving the display than with hot-plug detection and IOKit's USB device requirements.

感谢您的帮助！你们真棒.

Thanks for any help! You guys are awesome.

推荐答案

恐怕 kexts 并没有严格地动态链接自己(它们在运行时加载，但它们的结构是静态的)并且禁止一些英勇的自定义链接器/加载器的努力，你不会得到一个 dylib 加载到内核空间.

I'm afraid kexts aren't strictly dynamically linked themselves (they're loaded at runtime, but their structure is static) and barring some heroic custom linker/loader effort you won't get a dylib to load into kernel space.

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

As far as I know, the point of libusb is to write USB drivers in user space. It's therefore not clear to me why you're building a kext (which will run in kernel space) in the first place. Is there some element of the device that can't be driven from userspace using libusb? If so, try to make a kext only for that component and put the rest of the driver in a userspace daemon.

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

If splitting between libusb and your kernel-only component won't work, you'll need to use the kernel-space IOKit USB API in your kext. You can probably find a JPEG library that will compile statically, and which can be used in a kext (though not having a full libc will be an issue), but I strongly suspect you don't actually want to do this - JPEG (de)compression seems like it should be done in user space.

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

I get the impression you don't really need to deal with building your own kext at all - create a command-line (or GUI) app, link libusb and jpeglib to it, and do it all in user space. If you want it to go into the background, use the usual fork() method to daemonise your process, using a pipe, socket or other IPC to communicate with consumers of your driver. If you can somehow avoid writing a single line of kernel code, I'd strongly recommend sticking to user space. Debugging kernel code is a massive pain, and the more complex the driver, the worse it gets (I'd consider JPEG de/compression to be complex).

像往常一样，更多信息会很有用，尤其是我提到的部分.

As usual, more information would be useful, particularly on the parts I mention.

这篇关于在 Kexts 中链接 Dylib?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！