| /linux/fs/ntfs3/ |
| H A D | attrlist.c | 17 * Return: True if @le is valid.
20 struct ATTR_LIST_ENTRY *le) in al_is_valid_le() argument
23 if (!le || !ni->attr_list.le || !ni->attr_list.size) in al_is_valid_le()
26 return PtrOffset(ni->attr_list.le, le) + le16_to_cpu(le->size) <= in al_is_valid_le()
34 kvfree(ni->attr_list.le); in al_destroy()
35 ni->attr_list.le = NULL; in al_destroy()
50 void *le = NULL; in ntfs_load_attr_list() local
64 le = kvmalloc(al_aligned(lsize), GFP_KERNEL); in ntfs_load_attr_list()
65 if (!le) { in ntfs_load_attr_list()
69 memcpy(le, resident_data(attr), lsize); in ntfs_load_attr_list()
[all …]
|
| H A D | frecord.c | 177 int ni_load_mi(struct ntfs_inode *ni, const struct ATTR_LIST_ENTRY *le, in ni_load_mi() argument
183 if (!le) { in ni_load_mi()
188 rno = ino_get(&le->ref); in ni_load_mi()
206 struct ATTR_LIST_ENTRY *le; in ni_find_attr() local
223 le = al_find_ex(ni, le_o ? *le_o : NULL, type, name, name_len, vcn); in ni_find_attr()
224 if (!le) in ni_find_attr()
228 *le_o = le; in ni_find_attr()
231 if (ni_load_mi(ni, le, &m)) in ni_find_attr()
235 attr = mi_find_attr(ni, m, NULL, type, name, name_len, &le->id); in ni_find_attr()
264 struct ATTR_LIST_ENTRY **le, in ni_enum_attr_ex() argument
[all …]
|
| H A D | attrib.c | 255 struct ATTR_LIST_ENTRY *le, struct mft_inode *mi, in attr_make_nonresident() argument
342 if (le) in attr_make_nonresident()
343 al_remove_le(ni, le); in attr_make_nonresident()
383 struct ATTR_LIST_ENTRY *le, struct mft_inode *mi, in attr_set_size_res() argument
401 return attr_make_nonresident(ni, attr, le, mi, new_size, in attr_set_size_res()
444 struct ATTR_LIST_ENTRY *le, *le_b; in attr_set_size_ex() local
544 le = le_b; in attr_set_size_ex()
550 le = le_b; in attr_set_size_ex()
551 attr = ni_find_attr(ni, attr_b, &le, type, name, name_len, &vcn, in attr_set_size_ex()
564 * attr,mi,le - last attribute segment (containing 'vcn'). in attr_set_size_ex()
[all …]
|
| /linux/sound/core/ |
| H A D | pcm_misc.c | 22 signed char le; /* 0 = big-endian, 1 = little-endian, -1 = others */ member
34 .width = 8, .phys = 8, .le = -1, .signd = 1,
38 .width = 8, .phys = 8, .le = -1, .signd = 0,
42 .width = 16, .phys = 16, .le = 1, .signd = 1,
46 .width = 16, .phys = 16, .le = 0, .signd = 1,
50 .width = 16, .phys = 16, .le = 1, .signd = 0,
54 .width = 16, .phys = 16, .le = 0, .signd = 0,
58 .width = 24, .phys = 32, .le = 1, .signd = 1,
62 .width = 24, .phys = 32, .le = 0, .signd = 1,
66 .width = 24, .phys = 32, .le
[all...] |
| /linux/Documentation/translations/it_IT/process/ |
| H A D | submitting-patches.rst | 14 suggerimenti che aumenteranno significativamente le probabilità di vedere le
25 Questa documentazione assume che sappiate usare ``git`` per preparare le patch.
44 sorgenti e desiderano che le patch siano preparate basandosi su di essi.
51 Descrivete le vostre modifiche
66 singolarmente le patch dai sorgenti principali; quindi, includete tutte
67 le informazioni che possono essere utili a capire le vostre modifiche:
68 le circostanze che causano il problema, estratti da dmesg, descrizioni di
72 Quantificare le ottimizzazioni e i compromessi. Se affermate di aver
73 migliorato le prestazioni, il consumo di memoria, l'impatto sollo stack,
76 che non sono ovvi. Solitamente le ottimizzazioni non sono gratuite, ma sono
[all …]
|
| H A D | botching-up-ioctls.rst | 15 unificata per gestire la memoria e le unità esecutive di diverse GPU. Dunque,
19 dedicate. Ma al tempo stesso è più facile incasinare le cose.
23 focalizzano sui tecnicismi e non sulla visione d'insieme, come le discussioni
40 esplicitamente i vuoti. Non necessariamente le piattaforme a 32-bit allineano
41 i valori a 64-bit rispettandone l'allineamento, ma le piattaforme a 64-bit lo
54 vostro codice perché questo riduce le verifiche che strumenti come sparse
59 Le Basi
75 * Abbiate un piano per estendere le ioctl con nuovi *flag* o campi alla fine di
85 estendere le ioctl andrà a rotoli dato che qualcuno userà delle ioctl con
89 vuoti di tutte le vostre strutture dati, anche se non le userete in un
[all …]
|
| H A D | management-style.rst | 30 Prima di tutto, suggerirei di acquistare "Le sette regole per avere successo",
41 1) Le decisioni
52 Le persone che gestite devono conoscere i dettagli più di quanto li conosciate
56 (Corollario: se le persone che gestite non conoscono i dettagli meglio di voi,
60 Quindi il gioco si chiama "evitare" decisioni, almeno le più grandi e
63 del kernel ha bisogno di fare è trasformare le decisioni grandi e difficili
73 E le persone vedranno tutto ciò come prova di vera capacità di comando
76 Così la chiave per evitare le decisioni difficili diviene l'evitare
93 noi piace mantenere le apparenze, ed uscire allo scoperto in pubblico per
111 Poi, quando è realmente emersa la vostra stupidità, le persone semplicemente
[all …]
|
| H A D | submit-checklist.rst | 13 vedere le proprie patch accettate più rapidamente.
23 i file che le dichiarano/definiscono. Non dipendente dal fatto che un file
26 2) Controllate lo stile del codice della vostra patch secondo le direttive
29 3) Tutte le barriere di sincronizzazione {per esempio, ``barrier()``,
36 1) Le opzioni ``CONFIG``, nuove o modificate, non scombussolano il menu
41 2) Tutte le nuove opzioni ``Kconfig`` hanno un messaggio di aiuto.
60 5) Tutte le nuove interfacce verso lo spazio utente sono documentate in
63 Le patch che modificano le interfacce utente dovrebbero essere inviate
73 (``script/checkpatch.pl``) per scovare le violazioni più semplici.
74 Dovreste essere in grado di giustificare tutte le violazioni rimanenti nella
[all …]
|
| H A D | coding-style.rst | 16 considerazione le osservazioni espresse qui.
26 La tabulazione (tab) è di 8 caratteri e così anche le indentazioni. Ci sono
43 aggiunta vi avvisa quando state annidando troppo le vostre funzioni.
78 Non usate le virgole per evitare le parentesi:
85 Invece, usate sempre le parentesi per racchiudere più istruzioni.
112 Come limite di riga si preferiscono le 80 colonne.
115 pezzi più piccoli, a meno che eccedere le 80 colonne non aiuti ad
125 Tuttavia, non spezzettate mai le stringhe visibili agli utenti come i
146 Questo è valido per tutte le espressioni che non siano funzioni (if, switch,
162 Tuttavia, c'è il caso speciale, le funzioni: queste hanno la parentesi graffa
[all …]
|
| H A D | maintainer-pgp-guide.rst | 38 Sia i repositori git che gli archivi tar portano le firme PGP degli
40 offrono una garanzia crittografica che le versioni scaricabili rese disponibili
57 codice che gestisce l'infrastruttura, indipendentemente da quali che siano le
65 salvaguardare le chiavi PGP usate nello stabilire l'integrità del kernel Linux
87 Configurare le opzioni di gpg-agent
116 riguarda vecchie le versioni di GnuPG, poiché potrebbero non svolgere più
131 Le sottochiavi PGP
134 Raramente le chiavi PGP sono composte da una singola coppia -- solitamente, sono
147 come le vere chiavi passpartout in grado di aprire diverse serrature). Dato che
153 1. Tutte le sottochiavi sono indipendenti. Se perdete una sottochiave privata
[all …]
|
| H A D | 3.Early-stage.rst | 25 tende a confondere il problema reale con le soluzioni proposte e questo
29 linux audio cercarono un modo per far girare le applicazioni senza dropouts
41 e un rischio per la stabilità del sistema. Le loro soluzioni di punta nel
54 Cercare di comunicare le richieste degli utenti a queste persone è
78 Solo dopo ha senso iniziare a considerare le possibili soluzioni.
91 Non tutte le capacità del kernel sono documentate così bene come ci
131 inattendibili. Questi problemi (tra le altre cose) hanno tenuto AppArmor
143 la giusta lista di discussione e il giusto manutentore. Per le liste di
155 essere le persone che attualmente svolgono quel determinato ruolo. Quindi,
158 del sottosistema interessato. Controllate chi sta scrivendo le patch,
[all …]
|
| H A D | stable-api-nonsense.rst | 11 (tutte le risposte alle vostre domande e altro)
24 programmi, ovvero le chiamate di sistema. Queste interfacce sono **molto**
44 Solo le persone un po' strambe vorrebbero scrivere driver per il kernel con
71 un modo diverso di includere le funzioni (renderle inline oppure no).
106 Se parlate con le persone che cercano di mantenere aggiornato un driver per
112 interfacce attuali, o trovano modi migliori per fare le cose. Se le trovano,
113 allora le correggeranno per migliorarle. In questo frangente, i nomi delle
114 funzioni potrebbero cambiare, le strutture dati potrebbero diventare più grandi
116 Se questo dovesse succedere, nello stesso momento, tutte le istanze dove questa
136 le vecchie interfacce e sviluppare codice nel modo sbagliato, portando, di
[all …]
|
| H A D | 5.Posting.rst | 50 tutte le più ragionevoli combinazioni d'opzioni, usate cross-compilatori
56 sottosistemi. Per esempio, le funzioni di libreria (che risiedono in
84 Le patch devono essere preparate per una specifica versione del kernel.
98 Solo le modifiche più semplici dovrebbero essere preparate come una singola
100 modifiche. Spezzettare le patch è un po' un'arte; alcuni sviluppatori
107 Invece, le vostre modifiche dovranno essere considerate nella loro forma
188 le vostre parole. Queste includono i manutentori di un sotto-sistema, e i
190 le distribuzioni e altri manutentori che cercano di valutare se la patch
194 Un buon changelog fornisce le informazioni necessarie a tutte queste
206 successivi, ditelo. Se le API interne vengono cambiate, dettagliate queste
[all …]
|
| H A D | email-clients.rst | 15 al posto dei classici programmi di posta elettronica. Le pagine man sono
17 per applicare le patch.
20 stessi. Salvatela come testo includendo tutte le intestazioni. Poi eseguite
28 Le patch per il kernel vengono inviate per posta elettronica, preferibilmente
40 I programmi di posta elettronica che vengono usati per inviare le patch per il
49 Questo può corrompere le patch.
52 testo. Le patch inviate per posta elettronica dovrebbero essere codificate in
57 I programmi di posta dovrebbero generare e mantenere le intestazioni
60 Di solito, il copia-e-incolla (o taglia-e-incolla) non funziona con le patch
61 perché le tabulazioni vengono convertite in spazi. Usando xclipboard, xclip
[all …]
|
| H A D | volatile-considered-harmful.rst | 13 a volte saranno tentati dall'utilizzare *volatile* nel kernel per le
17 descrive le ragioni.
20 sopprimere le ottimizzazioni, che non è quasi mai quello che si vuole.
21 Nel kernel si devono proteggere le strutture dati condivise contro accessi
27 Come *volatile*, le primitive del kernel che rendono sicuro l'accesso ai dati
29 prevenire le ottimizzazioni indesiderate. Se vengono usate opportunamente,
33 rallentare le cose.
42 Se tutto il codice seguisse le regole di sincronizzazione, il valore di un
66 con i puntatori è sconsigliato e non funziona su tutte le architetture.
80 necessario. Ovviamente, tanto per puntualizzare, le attese attive sono
[all …]
|
| H A D | 2.Process.rst | 43 patch per un nuovo ciclo di sviluppo (e tutte le più importanti modifiche)
72 Mentre le correzioni si aprono la loro strada all'interno del ramo principale,
79 (tutte le date si collocano nel 2018)
99 particolarmente seri. Per questa ragione, le modifiche che portano ad una
103 L'obiettivo degli sviluppatori è quello di aggiustare tutte le regressioni
152 Le patch non passano direttamente dalla tastiera dello sviluppatori
155 ramo principale. Questo processo avviene velocemente per le correzioni
165 Una patch attraversa, generalmente, le seguenti fasi:
173 - Prima revisione. Le patch vengono pubblicate sulle liste di discussione
188 anche un lavoro quotidiano, quindi integrare le vostre patch potrebbe
[all …]
|
| H A D | 7.AdvancedTopics.rst | 16 Gestire le modifiche con git
27 Gestire le modifiche con git può rendere la vita dello sviluppatore molto
48 esplorare la storia della revisione, registrare le modifiche, usare i rami,
60 vi servirà, ovviamente, un server dal quale sia possibile attingere le vostre
81 anche se ci avete lavorato per mesi. Le modifiche possono essere spostate
88 perfetta. Riscrivere la storia riscriverà le patch contenute in quella
103 un ramo già pubblicato. Un esempio è linux-next dove le patch vengono
110 Man mano che il ramo principale (o altri rami su cui avete basato le
111 modifiche) avanza, diventa allettante l'idea di integrare tutte le patch
135 Potete inviarmi le vostre patch, ma per far si che io integri una
[all …]
|
| H A D | adding-syscalls.rst | 21 sistema è quella di valutare le alternative. Nonostante le chiamate di sistema
26 - Se le operazioni coinvolte possono rassomigliare a quelle di un filesystem,
36 - Tuttavia, le operazioni che non si sposano bene con operazioni tipo
63 Progettare l'API: pianificare le estensioni
76 del kernel e pianificate le estensioni fin dall'inizio)
104 di gestire un conflitto di versione in entrambe le direzioni:
130 nello spazio utente, la chiusura della finestra temporale fra le chiamate a
197 Al fine di rendere le nuove chiamate di sistema di facile revisione, è meglio
198 che dividiate le modifiche i pezzi separati. Questi dovrebbero includere
199 almeno le seguenti voci in *commit* distinti (ognuno dei quali sarà descritto
[all …]
|
| H A D | license-rules.rst | 16 aggiunge eccezione per le chiamate di sistema come descritto in
39 le interfacce usate dai programmi, e per questo sono un caso speciale.
40 Secondo le note nel file COPYING, le chiamate di sistema sono un chiaro
42 programmi che le usano per comunicare con il kernel. Dato che i file
134 Le eccezioni si possono usare solo in combinazione con identificatori di
170 Le licenze attualmente in uso, così come le licenze aggiunte al kernel, possono
175 Ovunque possibile le licenze qui indicate dovrebbero essere usate perché
204 Solitamente, questo è un unico identificatore valido, ma per esempio le
217 in un file sorgente in conformità con le linea guida in
258 o quando si prende codice da altri progetti. Le licenze sono disponibili
[all …]
|
| H A D | 6.Followthrough.rst | 12 A questo punto, avete seguito le linee guida fino a questo punto e, con
48 riconosciuto; le persone ricordano chi ha scritto il codice, ma meno
75 comunicarvi. Se possibile, sistemate le cose che il revisore vi chiede di
98 codice senza aver risposto ai commenti ricevuti, probabilmente le vostre
104 revisori le questioni sollevate precedetemene e come le avete risolte.
110 Se invece avete cercato di far tutto correttamente ma le cose continuano
120 le altre alternative. E tenete a mente, ovviamente, che nemmeno lui
130 sottosistema medesimo; ogni manutentore ha il proprio modo di fare le cose.
135 Per le modifiche proposte in aree per le quali non esiste un sottosistema
137 ripiego finiscono per essere -mm. Ed anche le modifiche che riguardano
[all …]
|
| /linux/tools/testing/selftests/powerpc/tm/ |
| H A D | tm-trap.c | 9 * The issue can be checked on LE machines simply by zeroing load_fp
20 * bit trickier to check it on BE machines because MSR.LE bit is set
24 * from the signal handler (as it happens on LE machines). Thus to test
25 * it on BE machines LE endianness is forced after a first trap and then
49 #define LE 1UL macro
57 int le; variable
66 /* Get thread endianness: extract bit LE from MSR */ in trap_signal_handler()
73 if (le) { in trap_signal_handler()
87 * endianness was still LE (not flipped inadvertently) in trap_signal_handler()
91 * LE endianness does in effect nothing, instruction (2) in trap_signal_handler()
[all …]
|
| /linux/Documentation/translations/it_IT/kernel-hacking/ |
| H A D | hacking.rst | 21 del kernel Linux ad opera di Rusty. Questo documento descrive le procedure
51 nell'esecuzione, ma un'interruzione hardware può. Ciò nonostante, le altre CPU
55 le interruzioni, così da impedirne davvero il diritto di prelazione.
62 o le interruzioni, possono far valere il proprio diritto di prelazione sul
68 e durante le operazioni nello strato dei dispositivi a blocchi
88 Dato che durante la loro esecuzione le interruzioni vengono disabilitate,
98 Attenzione, questa ritornerà un falso positivo se le interruzioni
161 parte di quelle a 64-bit; e spesso è condiviso con le interruzioni,
188 dev'essere dichiarato in tutte le architetture nei file
235 - Avete abilitato le interruzioni (in realtà, Andy Kleen dice che
[all …]
|
| /linux/arch/powerpc/crypto/ |
| H A D | ghashp10-ppc.pl | 75 le?xor r7,r7,r7
76 le?addi r7,r7,0x8 # need a vperm start with 08
77 le?lvsr 5,0,r7
78 le?vspltisb 6,0x0f
79 le?vxor 5,5,6 # set a b-endian mask
80 le?vperm $H,$H,$H,5
250 le?lvsl $lemask,r0,r0
252 le?vspltisb $t0,0x07
254 le?vxor $lemask,$lemask,$t0
256 le?vperm $IN,$IN,$IN,$lemask
[all …]
|
| /linux/Documentation/translations/it_IT/locking/ |
| H A D | lockstat.rst | 18 Perché, tanto per fare un esempio, le contese sui blocchi possono influenzare
19 significativamente le prestazioni.
25 mappa le istanze di blocco con le relative classi. Partiamo da questo punto
27 Il grafico sottostante mostra la relazione che intercorre fra le
51 lock, unlock - le classiche funzioni di blocco
55 Grazie a questi punti di collegamento possiamo fornire le seguenti statistiche:
106 Le statistiche sui blocchi si abilitano usando l'opzione di configurazione
120 Per vedere le statistiche correnti sui blocchi::
159 Questo estratto mostra le statistiche delle prime due classi di
161 cambierà ogni volta che cambia il formato. Le righe dalla 02 alla 04
[all …]
|
| /linux/Documentation/translations/it_IT/doc-guide/ |
| H A D | kernel-doc.rst | 19 generato il `dominio Sphinx per il C`_ con un'adeguata descrizione per le
20 funzioni ed i tipi di dato con i loro relativi collegamenti. Le descrizioni
27 Tutte le funzioni esportate verso i moduli esterni utilizzando
29 kernel-doc. Quando l'intenzione è di utilizzarle nei moduli, anche le funzioni
30 e le strutture dati nei file d'intestazione dovrebbero avere dei commenti
34 secondo kernel-doc per le funzioni che sono visibili da altri file del kernel
44 le funzioni che sono esportate verso i moduli esterni utilizzando
48 per le funzioni che sono visibili da altri file del kernel (ovvero, che non
56 Le strutture dati visibili nei file di intestazione dovrebbero essere anch'esse
89 Documentare le funzioni
[all …]
|