Lines Matching +full:non +full:- +full:l
1 .. include:: ../disclaimer-ita.rst
3 :Original: :ref:`Documentation/process/adding-syscalls.rst <addsyscalls>`
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,
32 - Se la nuova funzionalità prevede operazioni dove il kernel notifica
36 - Tuttavia, le operazioni che non si sposano bene con operazioni tipo
41 - Se dovete esporre solo delle informazioni sul sistema, un nuovo nodo in
43 in procfs potrebbe essere sufficiente. Tuttavia, l'accesso a questi
44 meccanismi richiede che il filesystem sia montato, il che potrebbe non
46 Evitate d'aggiungere nuove API in debugfs perché questo non viene
48 - Se l'operazione è specifica ad un particolare file o descrittore, allora
49 potrebbe essere appropriata l'aggiunta di un comando :manpage:`fcntl(2)`.
55 - Se l'operazione è specifica ad un particolare processo, allora
56 potrebbe essere appropriata l'aggiunta di un comando :manpage:`prctl(2)`.
63 Progettare l'API: pianificare le estensioni
64 -------------------------------------------
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
79 il modo migliore di permettere l'estensibilità è quello di includere un
86 return -EINVAL;
88 (Se *flags* non viene ancora utilizzato, verificate che l'argomento sia zero)
96 u32 size; /* userspace sets p->size = sizeof(struct xyzzy_params) */
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
118 Progettare l'API: altre considerazioni
119 --------------------------------------
123 descrittore di file per accesso all'oggetto - non inventatevi nuovi tipi di
128 descrittore di file, allora l'argomento *flags* dovrebbe includere un valore
138 dovreste considerare che significato avrà l'uso delle chiamate di sistema
148 dovreste anche considerare se non sia più appropriata una versione
156 ``AT_EMPTY_PATH``, in pratica otterremmo gratuitamente l'operazione
159 - xyzzyat(AT_FDCWD, path, ..., 0) is equivalent to xyzzy(path,...)
160 - xyzzyat(fd, "", ..., AT_EMPTY_PATH) is equivalent to fxyzzy(fd, ...)
168 tipo cosicché scostamenti a 64-bit potranno essere supportati anche su
169 architetture a 32-bit.
171 Se la vostra nuova chiamata di sistema :manpage:`xyzzy(2)` prevede l'uso di
178 evitate di aggiungere nuovi usi al fin-troppo-generico privilegio
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
194 Proporre l'API
195 --------------
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
215 linux-[email protected].
219 ------------------------------------------------
226 per definire i suoi parametri. L'uso di questa macro permette di avere
240 ``include/uapi/asm-generic/unistd.h``::
246 l'aggiunta della nuove chiamate di sistema; va notato che se più di una nuova
252 ritornano ``-ENOSYS``. Aggiungete la vostra nuova chiamata di sistema anche
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
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 ---------------------------------------------
286 nuova chiamata di sistema non sia particolarmente speciale (vedere sotto),
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
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
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
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
332 (Da notare che non serve questo livello di compatibilità per argomenti che
333 sono puntatori ad un tipo esplicitamente a 64-bit; per esempio, in
334 :manpage:`splice(2)` l'argomento di tipo ``loff_t __user *`` non necessita
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.
382 aggiustata al fine di permettere l'uso della versione *compatibile*;
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 ---------------------------------------------
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.
418 quindi gli argomenti dovrebbero corrispondere a quelli a 32-bit, e la voce in
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
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
448 l'architettura del programma (``execve``/``execveat``).
450 Per permettere tutto ciò, l'implementazione nel kernel di questo tipo di
453 su dove e come l'esecuzione dovrà continuare dopo l'esecuzione della
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
478 la versione ``compat_sys_`` piuttosto che quella nativa a 64-bit. In aggiunta,
479 se l'implementazione dell'ABI x32 è diversa da quella x86_64, allora la sua
484 *user-mode* Linux (UML) continui a funzionare -- la sua tabella di syscall
485 farà riferimento a stub_xyzzy, ma UML non include l'implementazione
494 --------------
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
510 di sistema esistente per verificare che non ci siano altri casi speciali.
514 --------
517 ai revisori un programma in spazio utente che mostri l'uso della chiamata di
519 semplice programma di auto-verifica in una nuova cartella in
522 Per una nuova chiamata di sistema, ovviamente, non ci sarà alcuna funzione
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).
533 dovreste considerare l'aggiunta di nuove verifica al progetto 'Linux Test',
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-[email protected]
551 https://www.kernel.org/doc/man-pages/patches.html
554 Non invocate chiamate di sistema dal kernel
555 -------------------------------------------
560 spazio utente attraverso la tabella syscall, ma non da nessun altro punto nel
569 Sui sistemi x86 a 64-bit, a partire dalla versione v4.17 è un requisito
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
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
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-[email protected]
625 - Consigli da Ingo Molnar che le chiamate di sistema con più argomenti
627 *size* per garantire l'estensibilità futura:
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: