Linking Dylibs in Kexts?

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.

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 -- t开发者_运维技巧he 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.

---

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.

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.

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.

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.