(IOKit) libusb と jpeglib を使用して USB ベースのフレームバッファを実装する OS X 用の kext を作成しました。これらはどちらも dylib であり、何らかの理由で XCode で適切にリンクされず、OS が kext をロードしようとしたときに依存関係が解決されません。
この全体の背景は、Samsung がセカンド モニターとして機能する LCD 額縁を製造していることです。唯一の問題は、それが DisplayLink やその他の既知のプロトコルではないことです。Windows 専用のドライバーはカスタム ヘッダーを吐き出し、各フレームは JPEG としてエンコードされ、デバイスに送信されます。私の実装では OS X でこれを行いますが、libusb はフレームバッファ デバイスであり、起動時にロードする必要があるため、libusb を使用しました。ホットプラグ検出や IOKit の USB デバイス要件よりも、ディスプレイの駆動にもっと対処したかったのです。
助けてくれてありがとう！あなたたちは素晴らしいです。
残念ながら、kext 自体は厳密には動的にリンクされておらず (実行時にロードされますが、構造は静的です)、英雄的なカスタム リンカー/ローダーの努力を除けば、dylib をカーネル空間にロードすることはできません。
私が知る限り、libusb のポイントは、ユーザー空間に USB ドライバーを書き込むことです。したがって、最初に kext (カーネル空間で実行される) を構築する理由が明確ではありません。libusb を使用してユーザー空間から駆動できないデバイスの要素はありますか? その場合は、そのコンポーネントのみの kext を作成し、残りのドライバーをユーザー空間デーモンに配置してみてください。
libusb とカーネルのみのコンポーネント間の分割が機能しない場合は、kext でカーネル空間 IOKit USB API を使用する必要があります。おそらく、静的にコンパイルされ、kext で使用できる JPEG ライブラリを見つけることができます (ただし、完全な libc がないことが問題になります)。 )圧縮はユーザー空間で行う必要があるようです。
コマンドライン (または GUI) アプリを作成し、それに libusb と jpeglib をリンクして、すべてユーザー空間で実行するだけです。バックグラウンドで実行したい場合は、通常の fork() メソッドを使用してプロセスをデーモン化し、パイプ、ソケット、またはその他の IPC を使用してドライバーのコンシューマーと通信します。カーネル コードを 1 行も書かずに済むのであれば、ユーザー空間に固執することを強くお勧めします。カーネル コードのデバッグは非常に苦痛であり、ドライバーが複雑になればなるほど、状況は悪化します (JPEG の解凍/圧縮は複雑であると考えています)。
いつものように、特に私が言及した部分については、より多くの情報が役立ちます。