it_IT/process/adding-syscalls.rst

13 un'aggiunta ai soliti consigli su come proporre nuove modifiche
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
29    funzionalità in un modulo kernel piuttosto che essere sviluppata nel cuore
33        lo spazio utente su un avvenimento, allora restituire un descrittore
38        come chiamate :manpage:`ioctl(2)`, il che potrebbe portare ad un'API in
39        un qualche modo opaca.
41  - Se dovete esporre solo delle informazioni sul sistema, un nuovo nodo in
47    considerata un'interfaccia di 'produzione' verso lo spazio utente.
48  - Se l'operazione è specifica ad un particolare file o descrittore, allora
49    potrebbe essere appropriata l'aggiunta di un comando :manpage:`fcntl(2)`.
54    un semplice flag associato ad un descrittore di file).
55  - Se l'operazione è specifica ad un particolare processo, allora
56    potrebbe essere appropriata l'aggiunta di un comando :manpage:`prctl(2)`.
57    Come per :manpage:`fcntl(2)`, questa chiamata di sistema è un complesso
59    nel comando ``prctl`` oppure per leggere/scrivere un semplice flag relativo
67 dev'essere supportata per un periodo indefinito.  Per questo, è davvero
68 un'ottima idea quella di discutere apertamente l'interfaccia sulla lista
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
82 del kernel, verificate se *flags* contiene un qualsiasi valore sconosciuto,
90 Per chiamate di sistema più sofisticate che coinvolgono un numero più grande di
93 funzionare con future estensioni includendo un campo *size*::
102 Fintanto che un qualsiasi campo nuovo, diciamo ``param_4``, è progettato per
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.
122 riferimento ad un oggetto del kernel, allora questa dovrebbe usare un
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
131 ``xyzzy()`` e ``fcntl(fd, F_SETFD, FD_CLOEXEC)``, dove un inaspettato
137 Se la vostra nuova chiamata di sistema ritorna un nuovo descrittore di file,
139 della famiglia di :manpage:`poll(2)`. Rendere un descrittore di file pronto
141 spazio utente circa un evento associato all'oggetto del kernel.
143 Se la vostra nuova chiamata di sistema :manpage:`xyzzy(2)` ha un argomento
144 che è il percorso ad un file::
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
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
183 la chiamata ``ptrace_may_access()``) di modo che solo un processo chiamante
205  - preparare la nuova chiamata di sistema per un'architettura specifica,
207  - un programma di auto-verifica da mettere in ``tools/testing/selftests/``
239 chiamata di sistema aggiungendo un nuovo elemento alla lista in
258 controlla, dovrebbero essere opzionali. Quindi, aggiungete un'opzione
272 Per riassumere, vi serve un *commit* che includa:
274  - un'opzione ``CONFIG``per la nuova funzione, normalmente in ``init/Kconfig``
277  - un elemento nella tabella generica in ``include/uapi/asm-generic/unistd.h``
287 dovete aggiungere un elemento *common* (per x86_64 e x32) in
292 e un elemento per *i386* ``arch/x86/entry/syscalls/syscall_32.tbl``::
305 chiamata di sistema include esplicitamente un puntatore, questo viene gestito
308 Tuttavia, ci sono un paio di situazione dove diventa necessario avere un
312 Il primo caso è quando un kernel a 64-bit supporta anche programmi in spazio
315 è necessario quando un argomento di una chiamata di sistema è:
317  - un puntatore ad un puntatore
318  - un puntatore ad una struttura dati contenente a sua volta un puntatore
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
328 In questo caso, un valore che arriva ad un kernel a 64-bit da un'applicazione
333 sono puntatori ad un tipo esplicitamente a 64-bit; per esempio, in
391  - un ``COMPAT_SYSCALL_DEFINEn(xyzzy, ...)`` per il punto d'accesso
393  - un prototipo in ``include/linux/compat.h``
402 Per collegare una chiamata di sistema, su un'architettura x86, con la sua
407 un argomento aggiuntivo per indicare che un programma in spazio utente
408 a 32-bit, eseguito su un kernel a 64-bit, dovrebbe accedere tramite il punto
417 Se c'è un puntatore ad un puntatore, la decisione è semplice: x32 è ILP32,
431 abbiano un'esatta corrispondenza da x32 (-mx32) al loro equivalente a
446 Potrebbero ritornare ad un punto diverso (``rt_sigreturn``) o cambiare
452 aggiuntivi nello *stack* del kernel, permettendo così un controllo completo
461 Per l'architettura x86_64, questo è implementato come un punto d'accesso
468 L'equivalente per programmi a 32-bit eseguiti su un kernel a 64-bit viene
476 Se una chiamata di sistema necessita di un livello di compatibilità (come
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
524 inoltre, se la nuova chiamata di sistema prevede un nuova struttura dati
569 Sui sistemi x86 a 64-bit, a partire dalla versione v4.17 è un requisito
580 fra il kernel e l'utente.  Questo è un altro motivo per cui invocare
618    x86 dovrebbe avvenire in un *commit* differente:
620  - Consigli da Greg Kroah-Hartman circa la bontà d'avere una pagina man e un
626    dovrebbero incapsularli in una struttura che includa un argomento