| /linux-6.14.4/fs/ntfs3/ |
| D | attrlist.c | 17 * Return: True if @le is valid.
20 struct ATTR_LIST_ENTRY *le) in al_is_valid_le() argument
22 if (!le || !ni->attr_list.le || !ni->attr_list.size) in al_is_valid_le()
25 return PtrOffset(ni->attr_list.le, le) + le16_to_cpu(le->size) <= in al_is_valid_le()
32 kvfree(ni->attr_list.le); in al_destroy()
33 ni->attr_list.le = NULL; in al_destroy()
48 void *le = NULL; in ntfs_load_attr_list() local
56 le = kvmalloc(al_aligned(lsize), GFP_KERNEL); in ntfs_load_attr_list()
57 if (!le) { in ntfs_load_attr_list()
61 memcpy(le, resident_data(attr), lsize); in ntfs_load_attr_list()
[all …]
|
| D | frecord.c | 167 int ni_load_mi(struct ntfs_inode *ni, const struct ATTR_LIST_ENTRY *le, in ni_load_mi() argument
172 if (!le) { in ni_load_mi()
177 rno = ino_get(&le->ref); in ni_load_mi()
195 struct ATTR_LIST_ENTRY *le; in ni_find_attr() local
211 le = al_find_ex(ni, le_o ? *le_o : NULL, type, name, name_len, vcn); in ni_find_attr()
212 if (!le) in ni_find_attr()
216 *le_o = le; in ni_find_attr()
219 if (ni_load_mi(ni, le, &m)) in ni_find_attr()
223 attr = mi_find_attr(ni, m, NULL, type, name, name_len, &le->id); in ni_find_attr()
252 struct ATTR_LIST_ENTRY **le, in ni_enum_attr_ex() argument
[all …]
|
| /linux-6.14.4/sound/core/ |
| D | pcm_misc.c | 37 signed char le; /* 0 = big-endian, 1 = little-endian, -1 = others */ member
52 .width = 8, .phys = 8, .le = -1, .signd = 1,
56 .width = 8, .phys = 8, .le = -1, .signd = 0,
60 .width = 16, .phys = 16, .le = 1, .signd = 1,
64 .width = 16, .phys = 16, .le = 0, .signd = 1,
68 .width = 16, .phys = 16, .le = 1, .signd = 0,
72 .width = 16, .phys = 16, .le = 0, .signd = 0,
76 .width = 24, .phys = 32, .le = 1, .signd = 1,
80 .width = 24, .phys = 32, .le = 0, .signd = 1,
84 .width = 24, .phys = 32, .le = 1, .signd = 0,
[all …]
|
| /linux-6.14.4/Documentation/translations/it_IT/process/ |
| 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 …]
|
| 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 …]
|
| 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 …]
|
| D | howto.rst | 12 Esso contiene le istruzioni su come diventare uno sviluppatore
19 vi preghiamo di inviare le correzioni agli amministratori di questo
30 di spiegare alcune delle ragioni per le quali la comunità lavora in un
51 Le divisioni ``long long`` e numeri in virgola mobile non sono permessi.
53 riguardo gli strumenti e le estensioni in uso, e sfortunatamente non
72 del kernel Linux. Le persone presenti in queste liste non sono avvocati,
108 seguire le linee guida in questo documento. Molti amministratori
121 Seguire tali regole non garantirà il successo (tutte le patch sono soggette
144 dello sviluppo di Linux ed è molto importante per le persone che arrivano
161 Questo file descrive le regole sulle quali vengono basati i rilasci del
[all …]
|
| 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
62 informazioni. Le patch che modificano le interfacce utente dovrebbero
72 (``script/checkpatch.pl``) per scovare le violazioni più semplici.
73 Dovreste essere in grado di giustificare tutte le violazioni rimanenti nella
[all …]
|
| 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 …]
|
| D | maintainer-pgp-guide.rst | 36 Sia i repositori git che gli archivi tar portano le firme PGP degli
38 offrono una garanzia crittografica che le versioni scaricabili rese disponibili
55 codice che gestisce l'infrastruttura, indipendentemente da quali che siano le
63 salvaguardare le chiavi PGP usate nello stabilire l'integrità del kernel Linux
84 Configurare le opzioni di gpg-agent
113 riguarda vecchie le versioni di GnuPG, poiché potrebbero non svolgere più
128 Le sottochiavi PGP
131 Raramente le chiavi PGP sono composte da una singola coppia -- solitamente, sono
144 come le vere chiavi passpartout in grado di aprire diverse serrature). Dato che
150 1. Tutte le sottochiavi sono indipendenti. Se perdete una sottochiave privata
[all …]
|
| 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 …]
|
| 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 …]
|
| D | 4.Coding.rst | 19 sbagliare. Poi, l'attenzione si sposterà verso "il fare le cose
32 codice nel kernel che non rispetta le linee guida relative allo stile.
39 rispetta le norme; molti sviluppatori richiederanno che il codice sia
59 ma le modifiche di stile non dovrebbero essere fatte fini a se stesse.
67 le regole, per una riformattazione automatica e veloce del vostro codice
106 peggiorare le prestazioni; essi non appartengono al kernel Linux.
137 Le macro del preprocessore C presentano una serie di pericoli, inclusi
141 che ne risulterà sarà lo stesso, ma le funzioni inline sono più leggibili,
149 Comunque, anche le funzioni inline hanno i loro pericoli. I programmatori
151 di una chiamata a funzione. Queste funzioni, tuttavia, possono ridurre le
[all …]
|
| 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 …]
|
| 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 …]
|
| D | 5.Posting.rst | 50 tutte le più ragionevoli combinazioni d'opzioni, usate cross-compilatori
77 Le patch devono essere preparate per una specifica versione del kernel.
91 Solo le modifiche più semplici dovrebbero essere preparate come una singola
93 modifiche. Spezzettare le patch è un po' un'arte; alcuni sviluppatori
100 Invece, le vostre modifiche dovranno essere considerate nella loro forma
181 le vostre parole. Queste includono i manutentori di un sotto-sistema, e i
183 le distribuzioni e altri manutentori che cercano di valutare se la patch
187 Un buon changelog fornisce le informazioni necessarie a tutte queste
199 successivi, ditelo. Se le API interne vengono cambiate, dettagliate queste
211 Le etichette sopracitate danno un'idea di come una patch prende vita e sono
[all …]
|
| D | 2.Process.rst | 46 patch per un nuovo ciclo di sviluppo (e tutte le più importanti modifiche)
75 Mentre le correzioni si aprono la loro strada all'interno del ramo principale,
82 (tutte le date si collocano nel 2018)
102 particolarmente seri. Per questa ragione, le modifiche che portano ad una
106 L'obiettivo degli sviluppatori è quello di aggiustare tutte le regressioni
153 Le patch non passano direttamente dalla tastiera dello sviluppatori
156 ramo principale. Questo processo avviene velocemente per le correzioni
166 Una patch attraversa, generalmente, le seguenti fasi:
174 - Prima revisione. Le patch vengono pubblicate sulle liste di discussione
189 anche un lavoro quotidiano, quindi integrare le vostre patch potrebbe
[all …]
|
| /linux-6.14.4/tools/testing/selftests/powerpc/tm/ |
| 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-6.14.4/arch/powerpc/crypto/ |
| D | aesp8-ppc.pl | 80 # POWER8[le] 3.96/0.72 0.74 1.1
103 $LITTLE_ENDIAN = ($flavour=~/le$/) ? $SIZE_T : 0;
179 le?vspltisb $mask,0x0f # borrow $mask
181 le?vxor $key,$key,$mask # adjust for byte swap
184 vperm $in0,$in0,$in1,$key # align [and byte swap in LE]
274 vperm $in1,$in1,$tmp,$key # align [and byte swap in LE]
350 vperm $in1,$in1,$tmp,$key # align [and byte swap in LE]
474 le?vspltisb v4,0x0f
476 le?vxor v2,v2,v4
478 vperm v0,v0,v1,v2 # align [and byte swap in LE]
[all …]
|
| D | ghashp8-ppc.pl | 73 le?xor r7,r7,r7
74 le?addi r7,r7,0x8 # need a vperm start with 08
75 le?lvsr 5,0,r7
76 le?vspltisb 6,0x0f
77 le?vxor 5,5,6 # set a b-endian mask
78 le?vperm $H,$H,$H,5
123 le?lvsl $lemask,r0,r0
125 le?vspltisb $t0,0x07
127 le?vxor $lemask,$lemask,$t0
129 le?vperm $IN,$IN,$IN,$lemask
[all …]
|
| /linux-6.14.4/lib/ |
| D | test_uuid.c | 14 guid_t le; member
21 .le = GUID_INIT(0xc33f4995, 0x3701, 0x450e, 0x9f, 0xbf, 0x20, 0x6a, 0x2e, 0x98, 0xe5, 0x76),
26 .le = GUID_INIT(0x64b4371c, 0x77c1, 0x48f9, 0x82, 0x21, 0x29, 0xf0, 0x54, 0xfc, 0x02, 0x3b),
31 .le = GUID_INIT(0x0cb4ddff, 0xa545, 0x4401, 0x9d, 0x06, 0x68, 0x8a, 0xf5, 0x3e, 0x7f, 0x84),
52 be ? "BE" : "LE", in test_uuid_failed()
64 guid_t le; in test_uuid_test() local
68 /* LE */ in test_uuid_test()
70 if (guid_parse(data->uuid, &le)) in test_uuid_test()
74 if (!guid_equal(&data->le, &le)) { in test_uuid_test()
75 sprintf(buf, "%pUl", &le); in test_uuid_test()
[all …]
|
| /linux-6.14.4/drivers/gpio/ |
| D | gpiolib-cdev.c | 583 struct gpio_v2_line_event *le) in linereq_put_event() argument
592 kfifo_in(&lr->events, le, 1); in linereq_put_event()
642 struct gpio_v2_line_event le; in process_hw_ts_thread() local
652 memset(&le, 0, sizeof(le)); in process_hw_ts_thread()
654 le.timestamp_ns = line->timestamp_ns; in process_hw_ts_thread()
666 le.id = line_event_id(level); in process_hw_ts_thread()
669 le.id = GPIO_V2_LINE_EVENT_RISING_EDGE; in process_hw_ts_thread()
672 le.id = GPIO_V2_LINE_EVENT_FALLING_EDGE; in process_hw_ts_thread()
677 le.line_seqno = line->line_seqno; in process_hw_ts_thread()
678 le.seqno = (lr->num_lines == 1) ? le.line_seqno : line->req_seqno; in process_hw_ts_thread()
[all …]
|
| /linux-6.14.4/Documentation/translations/it_IT/dev-tools/ |
| D | clang-format.rst | 21 file che mantieni, le modifiche che revisioni, le differenze,
29 principale dei sorgenti del kernel. Le regole scritte in quel file tentano
30 di approssimare le lo stile di codifica del kernel. Si tenta anche di seguire
34 le regole di base per un particolare sottosistema o cartella. Per farlo,
68 Osservare le righe di questo diff è utile a migliorare/aggiustare
69 le opzioni di stile nel file di configurazione; così come per verificare
70 le nuove funzionalità/versioni di ``clang-format``.
104 complesso, macro multi-riga (e allineare le loro "barre"), eccetera.
106 Ricordatevi che potete sempre aggiustare le modifiche in quei casi dove
112 Al seguente indirizzo troverete le istruzioni:
[all …]
|
| /linux-6.14.4/Documentation/translations/it_IT/locking/ |
| D | locktypes.rst | 8 Tipologie di blocco e le loro istruzioni
35 unlock(). Inoltre, vanno prese in considerazione anche le varianti di *debug*
60 Su kernel non-PREEMPT_RT, le funzioni local_lock gestiscono le primitive di
77 Implicitamente, i blocchi ad attesa attiva disabilitano la prelazione e le
83 _irq() disabilita / abilita le interruzioni
84 _irqsave/restore() salva e disabilita le interruzioni / ripristina ed attiva le interruzioni
108 dove la prelazione o le interruzioni sono disabilitate; anche sui kernel
167 Sui kernel non-PREEMPT_RT le operazioni local_lock si traducono
168 nell'abilitazione o disabilitazione della prelazione o le interruzioni.
183 cosa si applichi la protezione cosa che invece non si può fare con le
[all …]
|
| /linux-6.14.4/Documentation/translations/it_IT/kernel-hacking/ |
| 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 …]
|