¿Necesito dos máquinas para desarrollar controladores de IOKIT MAC?

Question

Estoy construyendo un controlador IOKIT CFPLUGIN para OS X. Trabajaré con datos de red que se traducirán a datos MIDI. No hay hardware que no sea el aeropuerto incorporado. Tengo experiencia con los controladores en las máquinas y el firmware de Windows, pero este es mi primer chapuzón para hacerlo en la Mac. Hasta ahora, las cosas van bastante bien, pero la documentación de Apple SEZ: "Por razones de seguridad, no debe cargar su conductor en su máquina de desarrollo".

Solo tengo una Mac. Realmente no quiero dos Macs, lo siento, Apple. ¿Debería tomar esta advertencia en serio? ¿Hay cosas que necesito saber?

Gracias Tom Jeffries

Answer 1

También podría considerar ejecutar OS X dentro de una VM como su Testbed. Seguramente sería mucho más conveniente tener un volumen de arranque separado.

Answer 2

La advertencia está bastante mal redactada; Lo que debe considerar hacer es usar un volumen de arranque separado (partición) para probar su controlador, ya que es posible manejar arbitrariamente su sistema con su controlador. Si está haciendo desarrollo del núcleo en cualquier sistema operativo que no esté aislado de su sistema principal (a través de una VM, disco de arranque alternativo, etc.), ¡está loco!

Lo que puede ser un problema mayor es que no puede hacer ninguna depuración del núcleo, porque la única opción para eso es usar GDB en un sistema remoto de OS X. Para esto, es posible que desee considerar Ejecutando OS X en virtualización.

Answer 3

Definitivamente, desea tener alguna forma de recuperar una instalación de Fubar KEXT: una unidad externa de arranque o algo de lo que puede restaurar rápidamente: esta es la razón principal de la advertencia de Apple contra la ejecución de extensiones de kernos en desarrollo en su máquina de producción.

Nicholas tiene razón en que para depurar el uso de GDB (la única forma en el espacio del núcleo) necesita dos máquinas. Nunca he intentado usar una VM como sugiere Coxy, pero supongo que es factible (suponiendo que ejecute su KEXT en la máquina virtual y use la máquina host real para ejecutar GDB).

Mi El método preferido para el rastreo y la depuración en el núcleo es Kprintf () enrutado a Firewire (también conocido como Firewire Kprintf (Man FWKPFV)). Para esto, necesitas dos máquinas con puertos de firewire.

Finalmente, siendo un viejo músico de computadora, me pregunto por qué quieres programar un sintetizador MIDI (o transformador) en el nivel de la pila de red. Supongo que tendrías una experiencia mucho más gratificante trabajando en Userland (donde puedes usar matemáticas de puntos flotantes ...)

Si necesita algunos sugerencias o consejos, no dude en ponerse en contacto ...

| K

desde el Guía de programación del núcleo ADC

La programación del núcleo es un arte negro que debe evitarse si es posible. Afortunadamente, la programación del núcleo suele ser innecesaria. Puede escribir la mayoría de los software por completo en el espacio de usuario. Incluso la mayoría de los controladores de dispositivos (Firewire y USB, por ejemplo) pueden escribirse como aplicaciones, en lugar de como código del núcleo. Sin embargo, algunos conductores de bajo nivel deben ser residentes en el espacio de direcciones del kernel, y este documento podría ser marginalmente útil si está escribiendo conductores que entran en esta categoría.