Lines Matching +full:un +full:-
1 .. include:: ../disclaimer-ita.rst
3 :Original: Documentation/process/botching-up-ioctls.rst
9 Preso da: https://blog.ffwll.ch/2013/11/botching-up-ioctls.html
14 imparato negli ultimi anni è l'inutilità di cercare di creare un'interfaccia
17 inviare dei programmi alla GPU. Il che è va bene dato che non c'è più un insano
30 ------------
33 partenza e ritrovarvi ad aggiungere un livello di compatibilità a 32-bit.
40 esplicitamente i vuoti. Non necessariamente le piattaforme a 32-bit allineano
41 i valori a 64-bit rispettandone l'allineamento, ma le piattaforme a 64-bit lo
45 * Se una struttura dati contiene valori a 64-bit, allora fate si che la sua
46 dimensione sia allineata a 64-bit, altrimenti la sua dimensione varierà su
47 sistemi a 32-bit e 64-bit. Avere una dimensione differente causa problemi
51 * I puntatori sono di tipo ``__u64``, con un *cast* da/a ``uintptr_t`` da lato
60 -------
62 Con la gioia d'aver evitato un livello di compatibilità, possiamo ora dare uno
67 * Abbiate un modo chiaro per capire dallo spazio utente se una nuova ioctl, o
69 potete fidarvi del fatto che un vecchio kernel possa rifiutare correttamente
70 un nuovo *flag*, modalità, o ioctl, (probabilmente perché avevate raffazzonato
71 qualcosa nel passato) allora dovrete implementare nel driver un meccanismo per
72 notificare quali funzionalità sono supportate, o in alternativa un numero di
75 * Abbiate un piano per estendere le ioctl con nuovi *flag* o campi alla fine di
79 su un kernel vecchio non noterebbe che i campi nuovi alla fine della struttura
89 vuoti di tutte le vostre strutture dati, anche se non le userete in un
93 * Abbiate un semplice codice di test per ognuno dei casi sopracitati.
97 --------------------------------
101 validazione degli input e gestire in modo robusto i percorsi - tanto le GPU
107 posizionamento di un'immagine *sprite* quando l'hardware supporta giusto 12
112 * Avere un test semplice per ogni possibile fallimento della vostra ioctl.
114 assicuratevi che verifichiate un solo percorso sbagliato per ogni sotto-test
123 per i segnali, otterrete gratuitamente un eccellente copertura di base per
125 gestire la riesecuzione delle ioctl - per esempio, drm ha una piccola
131 * Se non potete rendere un pezzo di codice rieseguibile, almeno rendete
133 apprezzeranno affatto se tenete in ostaggio il loro scatolotto (mediante un
139 recupero del sistema - è troppo facile create uno stallo fra il vostro codice
140 anti-stallo e un processo scrittore.
144 --------------------------------
156 (fornito dal kernel) oppure un contatore hardware indipendente da qualche
176 avvocato delle specifiche diremmo che questo non è un baco perché tutte le
177 scadenze potrebbero essere estese - ma sicuramente gli utenti vi odieranno
183 sposa meglio in un applicazione guidata dagli eventi.
191 -------------------
192 Nel suo piccolo il driver drm implementa un sistema operativo specializzato per
199 dev'essere condivisa fra processi - passarsi descrittori di file sul socket
208 dispositivo. Un controesempio viene dall'interfaccia drm modeset, dove
216 sottomissione di un oggetto allo stesso comando ioctl. Ma per evitarlo, se
218 driver ha importato un oggetto da un altro processo. Non l'ho ancora provato,
220 descrittori di file condivisi - che poi è come si distinguono i veri file.
221 Sfortunatamente, questo richiederebbe lo sviluppo di un vero e proprio
226 ------------------------------
230 * Pensateci su due o tre volte prima di implementare un'interfaccia privata per
231 un driver. Ovviamente è molto più veloce seguire questa via piuttosto che
233 a volte un'interfaccia privata è quello che serve per sviluppare un nuovo
234 concetto. Ma alla fine, una volta che c'è un'interfaccia generica a
238 meglio per impostazioni che sono specifiche di un dispositivo, o per
239 sotto-oggetti con una vita piuttosto statica (come le uscite dei connettori in
242 debugfs (che non ha un'interfaccia stabile) sarà la soluzione migliore.