Lines Matching refs:la
27 allora potrebbe avere molto più senso la creazione di un nuovo filesystem o
28 dispositivo. Inoltre, questo rende più facile incapsulare la nuova
32 - Se la nuova funzionalità prevede operazioni dove il kernel notifica
51 nasconde una notevole complessità, quindi è ottima solo quando la nuova
53 la nuova funzionalità è veramente semplice (per esempio, leggere/scrivere
83 in qual caso rifiutate la chiamata di sistema (con ``EINVAL``)::
91 argomenti, il modo migliore è quello di incapsularne la maggior parte in una
107 programma in spazio utente verificando che la memoria oltre la dimensione
111 programma in spazio utente estendendo la struttura dati con zeri (in pratica
114 Vedere :manpage:`perf_event_open(2)` e la funzione ``perf_copy_attr()`` (in
121 Se la vostra nuova chiamata di sistema permette allo spazio utente di fare
127 Se la vostra nuova chiamata di sistema :manpage:`xyzzy(2)` ritorna un nuovo
130 nello spazio utente, la chiusura della finestra temporale fra le chiamate a
137 Se la vostra nuova chiamata di sistema ritorna un nuovo descrittore di file,
140 per la lettura o la scrittura è il tipico modo del kernel per notificare lo
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
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
166 Se la vostra nuova chiamata di sistema :manpage:`xyzzy(2)` prevede un parametro
171 Se la vostra nuova chiamata di sistema :manpage:`xyzzy(2)` prevede l'uso di
175 gestire la funzionalità associata, ma evitate la combinazione di diverse
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
187 Infine, state attenti che in alcune architetture non-x86 la vita delle chiamate
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
223 esplicito, lo aggiungerete tramite la macro ``SYSCALL_DEFINEn``. La 'n'
224 indica il numero di argomenti della chiamata di sistema; la macro ha come
238 tabella comune di syscall. Aggiungete alla lista generica la vostra nuova
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
263 sistema che la controlla.
266 - Nel Makefile, rendere tutti i nuovi file sorgenti, che implementano la
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``
284 Per collegare la vostra nuova chiamate di sistema alle piattaforme x86,
285 dovete aggiornate la tabella principale di syscall. Assumendo che la vostra
297 conflitti durante la finestra di integrazione.
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
338 ``compat_sys_xyzzy()``, e viene aggiunta utilizzando la macro
341 che trasformerà secondo le necessità (tipicamente, la versione
343 può chiamare la versione ``sys_`` oppure invocare una funzione che implementa
352 Se la chiamata di sistema prevede una struttura dati organizzata in modo
355 ``then the include/linux/compat.h`` deve includere la sua versione
359 può usare la struttura ``compat_`` per analizzare gli argomenti ricevuti
371 nella struttura ``struct xyzzy_args``, allora la struttura
383 la voce in ``include/uapi/asm-generic/unistd.h`` dovrebbero usare
402 Per collegare una chiamata di sistema, su un'architettura x86, con la sua
403 versione *compatibile*, è necessario aggiustare la voce nella tabella
406 Per prima cosa, la voce in ``arch/x86/entry/syscalls/syscall_32.tbl`` prende
414 per la versione dell'ABI x32. Qui C'è una scelta da fare: gli argomenti
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
420 x32 eseguano la chiamata *compatibile*::
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
441 stesso *stack* e con la maggior parte del registri com'erano stati
442 lasciati prima della chiamata di sistema, e anche con la stessa memoria
447 la memoria in spazio utente (``fork``/``vfork``/``clone``) o perfino
458 aggiuntivi e quindi chiamare il vero punto d'accesso per la chiamata di
462 ``stub_xyzzy`` in ``arch/x86/entry/entry_64.S``, e la voce nella tabella
470 ``arch/x86/entry/entry_64_compat.S`` con la corrispondente voce nella tabella
477 nella sezione precedente), allora la versione ``stub32_`` deve invocare
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
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
504 oppure multiplatori di socket (``socketcall``). Se la vostra nuova chiamata
509 vale la pena fare una ricerca con ``grep`` su tutto il kernel per la chiamata
524 inoltre, se la nuova chiamata di sistema prevede un nuova struttura dati
546 versione già convertita in formato ASCII: semplificherà la vita dei revisori.
560 spazio utente attraverso la tabella syscall, ma non da nessun altro punto nel
561 kernel. Se la nuova funzionalità è utile all'interno del kernel, per esempio
563 dev'essere utilizzata da una chiamata di sistema e la sua variante compatibile,
573 la chiamata di sistema la quale verrà eseguita successivamente.
598 percorso implementativo di una chiamata di sistema per la versione v3.14:
620 - Consigli da Greg Kroah-Hartman circa la bontà d'avere una pagina man e un
642 favorire la compatibilità con le versioni a 64-bit piuttosto che quelle a 32-bit: