Ricerca di opinioni sull'utilizzo dell'albero del dispositivo per la definizione I / O

Per evitare di fare una dichiarazione basata sull'opinione personale, ecco una risposta basata sulla mia esperienza nel campo della rete RF e programmatore di dispositivi ARM incorporato come osservatore di shenanigans interaziendali (piuttosto che come un partecipante / implementatore di collaborazione o standard )

Fattori da considerare quando decidi di supportare un determinato sforzo standard / collaborativo:

• Esistono più aziende rispetto ai soliti sospetti che sono spesso lì per minimizzare l'impatto sui giocatori dei propri interessi. = > Ci sono pochissime aziende coinvolte e al momento della scrittura non sembra esserci alcun sostegno reale da parte dei gruppi di utenti.

• Ci sono specifiche di rilascio stabilite su cui lavorare, oppure è tutto in aria forse aspettando (il litigio per morire e raggiungere) accordo = > nessuna versione realizzata, non una "collaborazione" matura.

• Devi unirti per avere accesso a documentazione apprezzabile = > Non lo so.

• È uno sforzo significativo per te implementare e mantenere la conformità = > Solo tu puoi dire.

• Esistono standard / "collaborazioni" in competizione che potrebbero ostacolare l'adozione di questa o essere una possibile alternativa scelta = > sì, per i dispositivi ARM c'è embed per cui ARM è un importante promotore.

In base alla semplice analisi di cui sopra suggerirei che l'albero dei dispositivi non dovrebbe essere la vostra massima priorità. NB: Questo non significa che non dovresti farlo però.

In generale:

• un sistema operativo dovrebbe utilizzare una sorta di struttura dati dell'albero per tenere traccia delle relazioni tra i pezzi di hardware

• (secondo me) questo dovrebbe essere un albero completo (per esempio dovrebbe includere lo scaldino per la tazza di caffè inserito in un hub USB inserito in un controller USB collegato a una porta thunderbolt) in modo che possa essere usato per la gestione dell'alimentazione (ad es. quali dispositivi collegati ad un hub USB devono essere messi in stato di riposo prima che l'hub USB sia messo in pausa?) e gli eventi hot plug (ad es. se l'hub USB viene rimosso, cos'altro deve essere stato rimosso?)

• un albero completo non può essere statico. Quasi tutto è potenzialmente hot plug (PCI, SATA, USB, ...) mentre il sistema operativo è in esecuzione (non solo quando il computer è spento), e quindi l'albero deve essere mantenuto / modificato dinamicamente mentre il sistema operativo è in esecuzione

• un albero completo ha bisogno di assistenza dai driver dei dispositivi. Quando si avvia un driver per una cosa (ad es. Controller USB), quel driver è responsabile della rilevazione di dispositivi figlio (ad esempio se un hub USB è collegato al controller USB, il driver del controller USB aggiunge "hub USB" all'albero).

• durante l'avvio, un sistema operativo dovrebbe utilizzare il rilevamento automatico il più possibile per costruire la struttura del dispositivo; perché è molto meno fastidioso per tutti (utenti finali, produttori di dispositivi, costruttori di sistemi, ...). Per le moderne macchine compatibili con PC 80x86, l'intero albero può essere costruito utilizzando esclusivamente il rilevamento automatico (principalmente a causa di una spinta a livello di settore negli anni '90 che è diventata necessaria perché le vecchie impostazioni "manuali dell'utente finale in config.sys" erano insostenibili e inadeguate per scopi hot-plug, che ha portato all'inclusione dell'enumerazione dei dispositivi incorporata in tutti gli standard successivi e agli standard "plug & play" che aggiungono retroattivamente funzionalità di scoperta a tecnologie meno recenti come ISA).

• purtroppo, specialmente per i sistemi embedded, ci sono casi in cui non è possibile utilizzare il rilevamento automatico. Per questi casi, un sistema operativo deve fare affidamento su "brutti intrusioni per aggirare i fallimenti di progettazione hardware" (ad esempio, la mancanza dell'enumerazione di dispositivi standardizzata).

Ora, nessuno dei precedenti ha nulla a che fare con DeviceTree - è tutto relativo al proprio albero interno del sistema operativo. Tuttavia, pensa a quell'ultimo punto elenco ...

DeviceTree è uno "standard de facto" relativamente valido che esiste (ed è utilizzato da più sistemi operativi) per riempire gli ultimi "brutti hack per aggirare la nicchia del design hardware". Per il suo scopo prefissato (che consente a un SO di inizializzare il suo albero interno fino al punto in cui possono iniziare il rilevamento automatico e i driver), non esiste un'alternativa migliore che io conosca.

In altre parole; (a mio parere) DeviceTree è la strada da percorrere per alcuni casi (ad esempio la maggior parte dei sistemi embedded) e non è sicuramente la strada da percorrere per altri casi (ad esempio sistemi 80x86 moderni, server ARM).