Lines Matching +full:un +full:-
1 .. include:: ../disclaimer-ita.rst
3 :Original: :ref:`Documentation/process/adding-syscalls.rst <addsyscalls>`
13 un'aggiunta ai soliti consigli su come proporre nuove modifiche
14 :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`.
18 ------------------------------------
23 ovvio, esistono altre possibilità - scegliete quella che meglio si adatta alle
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
32 - Se la nuova funzionalità prevede operazioni dove il kernel notifica
33 lo spazio utente su un avvenimento, allora restituire un descrittore
36 - Tuttavia, le operazioni che non si sposano bene con operazioni tipo
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
64 -------------------------------------------
67 dev'essere supportata per un periodo indefinito. Per questo, è davvero
68 un'ottima idea quella di discutere apertamente l'interfaccia sulla lista
73 non fu fatto, assieme ai corrispondenti aggiornamenti -
75 ``pipe``/``pipe2``, ``renameat``/``renameat2`` --quindi imparate dalla storia
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,
86 return -EINVAL;
90 Per chiamate di sistema più sofisticate che coinvolgono un numero più grande di
93 funzionare con future estensioni includendo un campo *size*::
96 u32 size; /* userspace sets p->size = sizeof(struct xyzzy_params) */
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.
119 --------------------------------------
122 riferimento ad un oggetto del kernel, allora questa dovrebbe usare un
123 descrittore di file per accesso all'oggetto - non inventatevi nuovi tipi di
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*
159 - xyzzyat(AT_FDCWD, path, ..., 0) is equivalent to xyzzy(path,...)
160 - xyzzyat(fd, "", ..., AT_EMPTY_PATH) is equivalent to fxyzzy(fd, ...)
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
168 tipo cosicché scostamenti a 64-bit potranno essere supportati anche su
169 architetture a 32-bit.
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
178 evitate di aggiungere nuovi usi al fin-troppo-generico privilegio
183 la chiamata ``ptrace_may_access()``) di modo che solo un processo chiamante
187 Infine, state attenti che in alcune architetture non-x86 la vita delle chiamate
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
195 --------------
202 - l'essenza dell'implementazione della chiamata di sistema, con i prototipi,
205 - preparare la nuova chiamata di sistema per un'architettura specifica,
207 - un programma di auto-verifica da mettere in ``tools/testing/selftests/``
209 - una bozza di pagina man per la nuova chiamata di sistema. Può essere
215 linux-api@vger.kernel.org.
219 ------------------------------------------------
239 chiamata di sistema aggiungendo un nuovo elemento alla lista in
240 ``include/uapi/asm-generic/unistd.h``::
252 ritornano ``-ENOSYS``. Aggiungete la vostra nuova chiamata di sistema anche
258 controlla, dovrebbero essere opzionali. Quindi, aggiungete un'opzione
262 - Includete una descrizione della nuova funzionalità e della chiamata di
264 - Rendete l'opzione dipendente da EXPERT se dev'essere nascosta agli utenti
266 - Nel Makefile, rendere tutti i nuovi file sorgenti, che implementano la
268 ``obj-$(CONFIG_XYZZY_SYSCALL) += xyzzy.o``).
269 - Controllate due volte che sia possibile generare il kernel con la nuova
272 Per riassumere, vi serve un *commit* che includa:
274 - un'opzione ``CONFIG``per la nuova funzione, normalmente in ``init/Kconfig``
275 - ``SYSCALL_DEFINEn(xyzzy, ...)`` per il punto d'accesso
276 - il corrispondente prototipo in ``include/linux/syscalls.h``
277 - un elemento nella tabella generica in ``include/uapi/asm-generic/unistd.h``
278 - *stub* di ripiego in ``kernel/sys_ni.c``
282 ---------------------------------------------
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``::
301 ------------------------------------------
303 Per molte chiamate di sistema, la stessa implementazione a 64-bit può essere
304 invocata anche quando il programma in spazio utente è a 32-bit; anche se la
305 chiamata di sistema include esplicitamente un puntatore, questo viene gestito
308 Tuttavia, ci sono un paio di situazione dove diventa necessario avere un
310 dimensioni fra 32-bit e 64-bit.
312 Il primo caso è quando un kernel a 64-bit supporta anche programmi in spazio
313 utente a 32-bit, perciò dovrà ispezionare aree della memoria (``__user``) che
314 potrebbero contenere valori a 32-bit o a 64-bit. In particolar modo, questo
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
327 a 64-bit anche su architetture a 32-bit, per esempio ``loff_t`` o ``__u64``.
328 In questo caso, un valore che arriva ad un kernel a 64-bit da un'applicazione
329 a 32-bit verrà diviso in due valori a 32-bit che dovranno essere riassemblati
333 sono puntatori ad un tipo esplicitamente a 64-bit; per esempio, in
340 dell'implementazione è parte del kernel a 64-bit ma accetta parametri a 32-bit
342 ``compat_sys_`` converte questi valori nello loro corrispondente a 64-bit e
353 diverso per sistemi a 32-bit e per quelli a 64-bit, diciamo
360 da una chiamata a 32-bit.
383 la voce in ``include/uapi/asm-generic/unistd.h`` dovrebbero usare
391 - un ``COMPAT_SYSCALL_DEFINEn(xyzzy, ...)`` per il punto d'accesso
393 - un prototipo in ``include/linux/compat.h``
394 - (se necessario) una struttura di compatibilità a 32-bit in
396 - una voce ``__SC_COMP``, e non ``__SYSCALL``, in
397 ``include/uapi/asm-generic/unistd.h``
400 ---------------------------------------------
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
415 possono corrisponde alla versione a 64-bit o a quella a 32-bit.
417 Se c'è un puntatore ad un puntatore, la decisione è semplice: x32 è ILP32,
418 quindi gli argomenti dovrebbero corrispondere a quelli a 32-bit, e la voce in
427 sistema a 64-bit per l'ABI x32 (e di conseguenza la voce in
431 abbiano un'esatta corrispondenza da x32 (-mx32) al loro equivalente a
432 32-bit (-m32) o 64-bit (-m64).
436 -----------------------------------------
440 in cui si erano interrotti -- quindi dall'istruzione successiva, con lo
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
478 la versione ``compat_sys_`` piuttosto che quella nativa a 64-bit. In aggiunta,
484 *user-mode* Linux (UML) continui a funzionare -- la sua tabella di syscall
494 --------------
500 Il sotto-sistema di controllo (*audit subsystem*) è uno di questi casi
502 tipi di chiamate di sistema -- in particolare apertura dei file
514 --------
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
524 inoltre, se la nuova chiamata di sistema prevede un nuova struttura dati
528 Assicuratevi che il programma di auto-verifica possa essere eseguito
530 funzioni quando viene compilato per x86_64 (-m64), x86_32 (-m32) e x32 (-mx32).
536 - https://linux-test-project.github.io/
537 - git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
541 ----------
548 Le pagine man dovrebbero essere in copia-conoscenza verso
549 linux-man@vger.kernel.org
551 https://www.kernel.org/doc/man-pages/patches.html
555 -------------------------------------------
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
589 -------------------
591 - Articolo di Michael Kerris su LWN sull'uso dell'argomento flags nelle
593 - Articolo di Michael Kerris su LWN su come gestire flag sconosciuti in
595 - Articolo di Jake Edge su LWN che descrive i limiti degli argomenti a 64-bit
597 - Una coppia di articoli di David Drysdale che descrivono i dettagli del
600 - https://lwn.net/Articles/604287/
601 - https://lwn.net/Articles/604515/
603 - Requisiti specifici alle architetture sono discussi nella pagina man
605 http://man7.org/linux/man-pages/man2/syscall.2.html#NOTES
606 - Collezione di email di Linux Torvalds sui problemi relativi a ``ioctl()``:
608 - "Come non inventare interfacce del kernel", Arnd Bergmann,
610 - Articolo di Michael Kerris su LWN sull'evitare nuovi usi di CAP_SYS_ADMIN:
612 - Raccomandazioni da Andrew Morton circa il fatto che tutte le informazioni
614 …ne di email: https://lore.kernel.org/r/20140724144747.3041b208832bbdf9fbce5d96@linux-foundation.org
615 - Raccomandazioni da Michael Kerrisk circa il fatto che le nuove chiamate di
617 - Consigli da Thomas Gleixner sul fatto che il collegamento all'architettura
618 x86 dovrebbe avvenire in un *commit* differente:
620 - Consigli da Greg Kroah-Hartman circa la bontà d'avere una pagina man e un
621 programma di auto-verifica per le nuove chiamate di sistema:
623 - Discussione di Michael Kerrisk sulle nuove chiamate di sistema contro
624 …l(2)`: https://lore.kernel.org/r/CAHO5Pa3F2MjfTtfNxa8LbnkeeU8=YJ+9tDqxZpw7Gz59E-4AUg@mail.gmail.com
625 - Consigli da Ingo Molnar che le chiamate di sistema con più argomenti
626 dovrebbero incapsularli in una struttura che includa un argomento
629 - Un certo numero di casi strani emersi dall'uso (riuso) dei flag O_*:
631 - commit 75069f2b5bfb ("vfs: renumber FMODE_NONOTIFY and add to uniqueness
633 - commit 12ed2e36c98a ("fanotify: FMODE_NONOTIFY and __O_SYNC in sparc
635 - commit bb458c644a59 ("Safer ABI for O_TMPFILE")
637 - Discussion from Matthew Wilcox about restrictions on 64-bit arguments:
638 https://lore.kernel.org/r/20081212152929.GM26095@parisc-linux.org
639 - Raccomandazioni da Greg Kroah-Hartman sul fatto che i flag sconosciuti dovrebbero
641 - Raccomandazioni da Linus Torvalds che le chiamate di sistema x32 dovrebbero
642 favorire la compatibilità con le versioni a 64-bit piuttosto che quelle a 32-bit: