Ho bisogno di due macchine per sviluppare i driver IOKit Mac?

Question

Sto costruendo un driver IOKIT CFPLUGIN per OS X. Lavorerò con i dati di rete in arrivo che verrà tradotto in dati MIDI. Nessun hardware è coinvolto se non l'aeroporto integrato. Ho esperienza con i driver su macchine e firmware Windows, ma questo è il mio primo tuffo nel farlo sul Mac. Finora le cose stanno andando abbastanza bene, ma la documentazione Apple SEZ: "Per motivi di sicurezza, non dovresti caricare il tuo driver sulla macchina di sviluppo".

Ho solo un Mac. Davvero non voglio due Mac: scusa, Apple. Dovrei prendere sul serio questo avvertimento? Ci sono cose che devo sapere?

Grazie, Tom Jeffries

Answer 1

Potresti anche prendere in considerazione l'esecuzione di OS X all'interno di una VM come letto di prova. Sarebbe sicuramente molto più conveniente che avere un volume di avvio separato.

Answer 2

L'avvertimento è piuttosto scarsamente formulato; Quello che dovresti prendere in considerazione è utilizzare un volume di avvio separato (partizione) per provare il driver, poiché è possibile trappolare arbitrariamente il sistema con il driver. Se stai facendo lo sviluppo del kernel su qualsiasi sistema operativo che non è isolato dal tuo sistema principale (tramite una VM, disco di avvio alternativo, ecc.), Sei pazzo!

Quello che potrebbe essere un problema più grande è che non è possibile eseguire il debug del kernel, perché l'unica opzione per questo è utilizzare GDB su un sistema OS X remoto. Per questo, potresti voler considerare Esecuzione di OS X in virtualizzazione.

Answer 3

Vuoi assolutamente avere un modo per recuperare un'installazione di Fubar Kext: un'unità esterna avviabile o qualcosa da cui puoi ripristinare rapidamente-questo è il motivo principale dell'avvertimento di Apple di eseguire le estensioni in-sviluppatore-kernel sul tuo computer di produzione.

Nicholas ha ragione che per debug utilizzando GDB (l'unico modo nello spazio del kernel) hai bisogno di due macchine. Non ho mai provato a usare una VM come suggerisce Coxy: ma immagino sia fattibile (supponendo che tu esegui il tuo kext sulla macchina virtuale e usi la macchina host reale per eseguire GDB).

Mio Il metodo preferito per la traccia e il debug nel kernel è Kprintf () instradato a FireWire (aka Firewire Kprintf (Man fwkpfv)). Per questo hai bisogno di due macchine con porte Firewire.

Infine, essendo un vecchio musicista per computer, mi chiedo perché vuoi programmare un sintetizzatore (o trasformatore) MIDI a livello di stack di rete. La mia ipotesi è che avresti un'esperienza molto più gratificante che lavora in Userland (dove puoi usare la matematica fluttuante ...)

Se hai bisogno di suggerimenti o suggerimenti, sentiti libero di metterti in contatto ...

| K

dal Guida alla programmazione del kernel ADC

La programmazione del kernel è un'arte nera che dovrebbe essere evitata se possibile. Fortunatamente, la programmazione del kernel è generalmente inutile. Puoi scrivere la maggior parte del software interamente nello spazio utente. Anche la maggior parte dei driver di dispositivi (Firewire e USB, ad esempio) può essere scritta come applicazioni, piuttosto che come codice del kernel. Alcuni driver di basso livello devono essere residenti nello spazio degli indirizzi del kernel, tuttavia, e questo documento potrebbe essere marginalmente utile se si scrivono driver che rientrano in questa categoria.