Lines Matching refs:di
8 Aggiungere una nuova chiamata di sistema
12 nuove chiamate di sistema al kernel Linux; questo è da considerarsi come
17 Alternative alle chiamate di sistema
20 La prima considerazione da fare quando si aggiunge una nuova chiamata di
21 sistema è quella di valutare le alternative. Nonostante le chiamate di sistema
22 siano il punto di interazione fra spazio utente e kernel più tradizionale ed
26 - Se le operazioni coinvolte possono rassomigliare a quelle di un filesystem,
27 allora potrebbe avere molto più senso la creazione di un nuovo filesystem o
34 di file all'oggetto corrispondente permette allo spazio utente di
47 considerata un'interfaccia di 'produzione' verso lo spazio utente.
49 potrebbe essere appropriata l'aggiunta di un comando :manpage:`fcntl(2)`.
50 Tuttavia, :manpage:`fcntl(2)` è una chiamata di sistema multiplatrice che
54 un semplice flag associato ad un descrittore di file).
56 potrebbe essere appropriata l'aggiunta di un comando :manpage:`prctl(2)`.
57 Come per :manpage:`fcntl(2)`, questa chiamata di sistema è un complesso
66 Una nuova chiamata di sistema diventerà parte dell'API del kernel, e
68 un'ottima idea quella di discutere apertamente l'interfaccia sulla lista
69 di discussione del kernel, ed è altrettanto importante pianificarne eventuali
72 (Nella tabella delle chiamate di sistema sono disseminati esempi dove questo
78 Per semplici chiamate di sistema che accettano solo un paio di argomenti,
79 il modo migliore di permettere l'estensibilità è quello di includere un
80 argomento *flags* alla chiamata di sistema. Per assicurarsi che i programmi
83 in qual caso rifiutate la chiamata di sistema (con ``EINVAL``)::
90 Per chiamate di sistema più sofisticate che coinvolgono un numero più grande di
91 argomenti, il modo migliore è quello di incapsularne la maggior parte in una
104 di gestire un conflitto di versione in entrambe le direzioni:
106 - un vecchio kernel può gestire l'accesso di una versione moderna di un
110 - un nuovo kernel può gestire l'accesso di una versione vecchia di un
115 ``kernel/events/core.c``) per un esempio pratico di questo approccio.
121 Se la vostra nuova chiamata di sistema permette allo spazio utente di fare
123 descrittore di file per accesso all'oggetto - non inventatevi nuovi tipi di
125 ben definita per utilizzare i descrittori di file.
127 Se la vostra nuova chiamata di sistema :manpage:`xyzzy(2)` ritorna un nuovo
128 descrittore di file, allora l'argomento *flags* dovrebbe includere un valore
133 eseguito (Comunque, resistete alla tentazione di riutilizzare il valore di
134 ``O_CLOEXEC`` dato che è specifico dell'architettura e fa parte di una
135 enumerazione di flag ``O_*`` che è abbastanza ricca).
137 Se la vostra nuova chiamata di sistema ritorna un nuovo descrittore di file,
138 dovreste considerare che significato avrà l'uso delle chiamate di sistema
139 della famiglia di :manpage:`poll(2)`. Rendere un descrittore di file pronto
143 Se la vostra nuova chiamata di sistema :manpage:`xyzzy(2)` ha un argomento
154 in questione; in particolare, permette allo spazio utente di richiedere la
155 funzionalità su un descrittore di file già aperto utilizzando il *flag*
163 man :manpage:`openat(2)`; per un esempio di AT_EMPTY_PATH, leggere la pagina
166 Se la vostra nuova chiamata di sistema :manpage:`xyzzy(2)` prevede un parametro
167 per descrivere uno scostamento all'interno di un file, usate ``loff_t`` come
171 Se la vostra nuova chiamata di sistema :manpage:`xyzzy(2)` prevede l'uso di
172 funzioni riservate, allora dev'essere gestita da un opportuno bit di privilegio
174 :manpage:`capabilities(7)`. Scegliete un bit di privilegio già esistente per
175 gestire la funzionalità associata, ma evitate la combinazione di diverse
177 principio di *capabilities* di separare i poteri di root. In particolare,
178 evitate di aggiungere nuovi usi al fin-troppo-generico privilegio
181 Se la vostra nuova chiamata di sistema :manpage:`xyzzy(2)` manipola altri
183 la chiamata ``ptrace_may_access()``) di modo che solo un processo chiamante
188 di sistema con argomenti a 64-bit viene semplificata se questi argomenti
190 l'uso di coppie contigue di registri a 32-bit. (Questo non conta se gli
191 argomenti sono parte di una struttura dati che viene passata per puntatore).
197 Al fine di rendere le nuove chiamate di sistema di facile revisione, è meglio
202 - l'essenza dell'implementazione della chiamata di sistema, con i prototipi,
203 i numeri generici, le modifiche al Kconfig e l'implementazione *stub* di
205 - preparare la nuova chiamata di sistema per un'architettura specifica,
207 - un programma di auto-verifica da mettere in ``tools/testing/selftests/``
208 che mostri l'uso della chiamata di sistema.
209 - una bozza di pagina man per la nuova chiamata di sistema. Può essere
210 scritta nell'email di presentazione, oppure come modifica vera e propria
213 Le proposte di nuove chiamate di sistema, come ogni altro modifica all'API del
214 kernel, deve essere sottomessa alla lista di discussione
218 Implementazione di chiamate di sistema generiche
221 Il principale punto d'accesso alla vostra nuova chiamata di sistema
224 indica il numero di argomenti della chiamata di sistema; la macro ha come
225 argomento il nome della chiamata di sistema, seguito dalle coppie (tipo, nome)
226 per definire i suoi parametri. L'uso di questa macro permette di avere
227 i metadati della nuova chiamata di sistema disponibili anche per altri
230 Il nuovo punto d'accesso necessita anche del suo prototipo di funzione in
231 ``include/linux/syscalls.h``, marcato come asmlinkage di modo da abbinargli
232 il modo in cui quelle chiamate di sistema verranno invocate::
236 Alcune architetture (per esempio x86) hanno le loro specifiche tabelle di
237 chiamate di sistema (syscall), ma molte altre architetture condividono una
238 tabella comune di syscall. Aggiungete alla lista generica la vostra nuova
239 chiamata di sistema aggiungendo un nuovo elemento alla lista in
245 Aggiornate anche il contatore __NR_syscalls di modo che sia coerente con
246 l'aggiunta della nuove chiamate di sistema; va notato che se più di una nuova
247 chiamata di sistema viene aggiunga nella stessa finestra di sviluppo, il numero
248 della vostra nuova syscall potrebbe essere aggiustato al fine di risolvere i
251 Il file ``kernel/sys_ni.c`` fornisce le implementazioni *stub* di ripiego che
252 ritornano ``-ENOSYS``. Aggiungete la vostra nuova chiamata di sistema anche
257 La vostra nuova funzionalità del kernel, e la chiamata di sistema che la
262 - Includete una descrizione della nuova funzionalità e della chiamata di
278 - *stub* di ripiego in ``kernel/sys_ni.c``
281 Implementazione delle chiamate di sistema x86
284 Per collegare la vostra nuova chiamate di sistema alle piattaforme x86,
285 dovete aggiornate la tabella principale di syscall. Assumendo che la vostra
286 nuova chiamata di sistema non sia particolarmente speciale (vedere sotto),
297 conflitti durante la finestra di integrazione.
300 Chiamate di sistema compatibili (generico)
303 Per molte chiamate di sistema, la stessa implementazione a 64-bit può essere
305 chiamata di sistema include esplicitamente un puntatore, questo viene gestito
308 Tuttavia, ci sono un paio di situazione dove diventa necessario avere un
309 livello di gestione della compatibilità per risolvere le differenze di
315 è necessario quando un argomento di una chiamata di sistema è:
320 - un puntatore ad un tipo intero di dimensione variabile (``time_t``,
322 - un puntatore ad una struttura dati contenente un tipo intero di dimensione
325 Il secondo caso che richiede un livello di gestione della compatibilità è
326 quando uno degli argomenti di una chiamata a sistema è esplicitamente un tipo
330 in questo livello di compatibilità.
332 (Da notare che non serve questo livello di compatibilità per argomenti che
334 :manpage:`splice(2)` l'argomento di tipo ``loff_t __user *`` non necessita
335 di una chiamata di sistema ``compat_``)
337 La versione compatibile della nostra chiamata di sistema si chiamerà
346 Il punto d'accesso *compat* deve avere il corrispondente prototipo di funzione
347 in ``include/linux/compat.h``, marcato come asmlinkage di modo da abbinargli
348 il modo in cui quelle chiamate di sistema verranno invocate::
352 Se la chiamata di sistema prevede una struttura dati organizzata in modo
381 La lista generica delle chiamate di sistema ha bisogno di essere
382 aggiustata al fine di permettere l'uso della versione *compatibile*;
384 ``__SC_COMP`` piuttosto di ``__SYSCALL``::
394 - (se necessario) una struttura di compatibilità a 32-bit in
399 Compatibilità delle chiamate di sistema (x86)
402 Per collegare una chiamata di sistema, su un'architettura x86, con la sua
413 Secondo, dovete capire cosa dovrebbe succedere alla nuova chiamata di sistema
426 Se non ci sono puntatori, allora è preferibile riutilizzare la chiamata di
427 sistema a 64-bit per l'ABI x32 (e di conseguenza la voce in
435 Chiamate di sistema che ritornano altrove
438 Nella maggior parte delle chiamate di sistema, al termine della loro
442 lasciati prima della chiamata di sistema, e anche con la stessa memoria
445 Tuttavia, alcune chiamata di sistema fanno le cose in modo differente.
450 Per permettere tutto ciò, l'implementazione nel kernel di questo tipo di
451 chiamate di sistema potrebbero dover salvare e ripristinare registri
454 chiamata di sistema.
458 aggiuntivi e quindi chiamare il vero punto d'accesso per la chiamata di
463 di syscall (``arch/x86/entry/syscalls/syscall_64.tbl``) verrà corretta di
471 di syscall ``arch/x86/entry/syscalls/syscall_32.tbl`` corretta nel
476 Se una chiamata di sistema necessita di un livello di compatibilità (come
480 voce nella tabella di syscall dovrà chiamare uno *stub* che invoca la versione
484 *user-mode* Linux (UML) continui a funzionare -- la sua tabella di syscall
496 La maggior parte dei kernel tratta le chiamate di sistema allo stesso modo,
498 l'aggiornamento della vostra chiamata di sistema.
500 Il sotto-sistema di controllo (*audit subsystem*) è uno di questi casi
502 tipi di chiamate di sistema -- in particolare apertura dei file
504 oppure multiplatori di socket (``socketcall``). Se la vostra nuova chiamata
505 di sistema è simile ad una di queste, allora il sistema di controllo dovrebbe
508 Più in generale, se esiste una chiamata di sistema che è simile alla vostra,
510 di sistema esistente per verificare che non ci siano altri casi speciali.
516 Una nuova chiamata di sistema dev'essere, ovviamente, provata; è utile fornire
517 ai revisori un programma in spazio utente che mostri l'uso della chiamata di
518 sistema. Un buon modo per combinare queste cose è quello di aggiungere un
519 semplice programma di auto-verifica in una nuova cartella in
522 Per una nuova chiamata di sistema, ovviamente, non ci sarà alcuna funzione
523 in libc e quindi il programma di verifica dovrà invocarla usando ``syscall()``;
524 inoltre, se la nuova chiamata di sistema prevede un nuova struttura dati
526 installato al fine di compilare il programma.
528 Assicuratevi che il programma di auto-verifica possa essere eseguito
532 Al fine di una più meticolosa ed estesa verifica della nuova funzionalità,
533 dovreste considerare l'aggiunta di nuove verifica al progetto 'Linux Test',
543 Tutte le nuove chiamate di sistema dovrebbero avere una pagina man completa,
545 state usando groff, è utile che includiate nella email di presentazione una
554 Non invocate chiamate di sistema dal kernel
557 Le chiamate di sistema sono, come già detto prima, punti di interazione fra
558 lo spazio utente e il kernel. Perciò, le chiamate di sistema come
562 dev'essere condivisa fra una vecchia e una nuova chiamata di sistema o
563 dev'essere utilizzata da una chiamata di sistema e la sua variante compatibile,
564 allora dev'essere implementata come una funzione di supporto
570 fondamentale quello di non invocare chiamate di sistema all'interno del kernel.
571 Esso usa una diversa convenzione per l'invocazione di chiamate di sistema dove
573 la chiamata di sistema la quale verrà eseguita successivamente.
575 necessari ad una specifica chiamata di sistema, invece che riempire ogni volta
577 causare seri problemi nella sequenza di chiamate).
584 che surclassano quelle generiche, per funzioni d'architettura di compatibilità,
591 - Articolo di Michael Kerris su LWN sull'uso dell'argomento flags nelle
592 chiamate di sistema: https://lwn.net/Articles/585415/
593 - Articolo di Michael Kerris su LWN su come gestire flag sconosciuti in
594 una chiamata di sistema: https://lwn.net/Articles/588444/
595 - Articolo di Jake Edge su LWN che descrive i limiti degli argomenti a 64-bit
596 delle chiamate di sistema: https://lwn.net/Articles/311630/
597 - Una coppia di articoli di David Drysdale che descrivono i dettagli del
598 percorso implementativo di una chiamata di sistema per la versione v3.14:
606 - Collezione di email di Linux Torvalds sui problemi relativi a ``ioctl()``:
610 - Articolo di Michael Kerris su LWN sull'evitare nuovi usi di CAP_SYS_ADMIN:
613 su una nuova chiamata di sistema dovrebbero essere contenute nello stesso
614 …filone di discussione di email: https://lore.kernel.org/r/20140724144747.3041b208832bbdf9fbce5d96@…
615 - Raccomandazioni da Michael Kerrisk circa il fatto che le nuove chiamate di
621 programma di auto-verifica per le nuove chiamate di sistema:
623 - Discussione di Michael Kerrisk sulle nuove chiamate di sistema contro
625 - Consigli da Ingo Molnar che le chiamate di sistema con più argomenti
629 - Un certo numero di casi strani emersi dall'uso (riuso) dei flag O_*:
641 - Raccomandazioni da Linus Torvalds che le chiamate di sistema x32 dovrebbero