Lines Matching full:per
11 Questo documento descrive quello che è necessario sapere per aggiungere
35 utilizzare ``poll``/``select``/``epoll`` per ricevere quelle notifiche.
45 essere sempre vero (per esempio, in ambienti come namespace/sandbox/chroot).
53 la nuova funzionalità è veramente semplice (per esempio, leggere/scrivere
57 Come per :manpage:`fcntl(2)`, questa chiamata di sistema è un complesso
58 multiplatore quindi è meglio usarlo per cose molto simili a quelle esistenti
59 nel comando ``prctl`` oppure per leggere/scrivere un semplice flag relativo
67 dev'essere supportata per un periodo indefinito. Per questo, è davvero
78 Per semplici chiamate di sistema che accettano solo un paio di argomenti,
80 argomento *flags* alla chiamata di sistema. Per assicurarsi che i programmi
90 Per chiamate di sistema più sofisticate che coinvolgono un numero più grande di
92 struttura dati che verrà passata per puntatore. Questa struttura potrà
102 Fintanto che un qualsiasi campo nuovo, diciamo ``param_4``, è progettato per
115 ``kernel/events/core.c``) per un esempio pratico di questo approccio.
123 descrittore di file per accesso all'oggetto - non inventatevi nuovi tipi di
125 ben definita per utilizzare i descrittori di file.
129 equivalente a ``O_CLOEXEC`` per i nuovi descrittori. Questo rende possibile,
140 per la lettura o la scrittura è il tipico modo del kernel per notificare lo
162 (Per maggiori dettagli sulla logica delle chiamate \*at(), leggete la pagina
163 man :manpage:`openat(2)`; per un esempio di AT_EMPTY_PATH, leggere la pagina
167 per descrivere uno scostamento all'interno di un file, usate ``loff_t`` come
174 :manpage:`capabilities(7)`. Scegliete un bit di privilegio già esistente per
191 argomenti sono parte di una struttura dati che viene passata per puntatore).
205 - preparare la nuova chiamata di sistema per un'architettura specifica,
209 - una bozza di pagina man per la nuova chiamata di sistema. Può essere
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
236 Alcune architetture (per esempio x86) hanno le loro specifiche tabelle di
259 ``CONFIG`` (solitamente in ``init/Kconfig``). Come al solito per le nuove
267 nuova funzionalità, dipendenti dall'opzione CONFIG (per esempio
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
284 Per collegare la vostra nuova chiamate di sistema alle piattaforme x86,
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``::
303 Per molte chiamate di sistema, la stessa implementazione a 64-bit può essere
309 livello di gestione della compatibilità per risolvere le differenze di
327 a 64-bit anche su architetture a 32-bit, per esempio ``loff_t`` o ``__u64``.
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
353 diverso per sistemi a 32-bit e per quelli a 64-bit, diciamo
359 può usare la struttura ``compat_`` per analizzare gli argomenti ricevuti
362 Per esempio, se avete i seguenti campi::
391 - un ``COMPAT_SYSCALL_DEFINEn(xyzzy, ...)`` per il punto d'accesso
402 Per collegare una chiamata di sistema, su un'architettura x86, con la sua
406 Per prima cosa, la voce in ``arch/x86/entry/syscalls/syscall_32.tbl`` prende
407 un argomento aggiuntivo per indicare che un programma in spazio utente
414 per la versione dell'ABI x32. Qui C'è una scelta da fare: gli argomenti
427 sistema a 64-bit per l'ABI x32 (e di conseguenza la voce in
450 Per permettere tutto ciò, l'implementazione nel kernel di questo tipo di
456 Queste saranno specifiche per ogni architettura, ma tipicamente si definiscono
457 dei punti d'accesso in *assembly* per salvare/ripristinare i registri
458 aggiuntivi e quindi chiamare il vero punto d'accesso per la chiamata di
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
483 Per completezza, sarebbe carino impostare una mappatura cosicché
497 ma possono esserci rare eccezioni per le quali potrebbe essere necessario
501 speciali; esso include (per architettura) funzioni che classificano alcuni
509 vale la pena fare una ricerca con ``grep`` su tutto il kernel per la chiamata
510 di sistema esistente per verificare che non ci siano altri casi speciali.
518 sistema. Un buon modo per combinare queste cose è quello di aggiungere un
522 Per una nuova chiamata di sistema, ovviamente, non ci sarà alcuna funzione
529 correttamente su tutte le architetture supportate. Per esempio, verificate che
530 funzioni quando viene compilato per x86_64 (-m64), x86_32 (-m32) e x32 (-mx32).
534 oppure al progetto xfstests per cambiamenti relativi al filesystem.
550 Per maggiori dettagli, leggere
561 kernel. Se la nuova funzionalità è utile all'interno del kernel, per esempio
565 (*helper function*) (per esempio ``ksys_xyzzy()``). Questa funzione potrà
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
583 Eccezioni a questa regola vengono accettate solo per funzioni d'architetture
584 che surclassano quelle generiche, per funzioni d'architettura di compatibilità,
585 o per altro codice in arch/
598 percorso implementativo di una chiamata di sistema per la versione v3.14:
621 programma di auto-verifica per le nuove chiamate di sistema:
627 *size* per garantire l'estensibilità futura: