| /kernel/linux/linux-6.6/Documentation/translations/it_IT/process/ |
| D | 5.Posting.rst | 66 Come regola generale, pensarci un po' di più prima di inviare il codice
78 Come regola generale, una patch dovrebbe basarsi sul ramo principale attuale
79 così come lo si trova nei sorgenti git di Linus. Quando vi basate sul ramo
91 Solo le modifiche più semplici dovrebbero essere preparate come una singola
92 patch; tutto il resto dovrebbe essere preparato come una serie logica di
94 passano molto tempo nel capire come farlo in modo che piaccia alla comunità.
99 come quella che trovate nel vostro sistema di controllo di versione.
105 - Ogni modifica logicamente indipendente dovrebbe essere preparata come una
125 difficile così come quella di chi s'impegna nel nobile lavoro di
135 come una serie di patch, ma di lasciare questa infrastruttura inutilizzata
[all …]
|
| D | howto.rst | 8 Come partecipare allo sviluppo del kernel Linux
12 Esso contiene le istruzioni su come diventare uno sviluppatore
13 del kernel Linux e spiega come lavorare con la comunità di
24 Dunque, volete imparare come diventare sviluppatori del kernel Linux?
29 su come lavorare con la comunità. Il documento cercherà, inoltre,
57 Tenete a mente che state cercando di apprendere come lavorare con la comunità
82 insegneranno come interagire con la comunità del kernel. Quando nuove
84 relativi file di documentatione che spiegano come usarele.
114 Questo file descrive dettagliatamente come creare ed inviare una patch
125 Altre ottime descrizioni di come creare buone patch sono:
[all …]
|
| D | 7.AdvancedTopics.rst | 11 A questo punto, si spera, dovreste avere un'idea su come funziona il processo
33 documento al riguardo. Invece, qui ci concentriamo in particolare su come
46 base solida su come funziona git. Uno sviluppatore che sappia usare git
50 (come ``rebase``) è altrettanto utile. Git ha i propri concetti e la propria
80 riscritta come se fosse stata scritta in cima al ramo principale di oggi,
94 la storia che avete esposto ad altri, generalmente, dovrebbe essere vista come
121 può essere utile; questo strumento si ricorda come i conflitti di *merge*
124 Una delle lamentele più grosse e ricorrenti sull'uso di strumenti come git
169 migliore di imparare come programmare per il kernel che guardare il codice
179 i commenti come domande e non come critiche. Chiedere "Come viene rilasciato
|
| D | license-rules.rst | 16 aggiunge eccezione per le chiamate di sistema come descritto in
19 Questo documento fornisce una descrizione su come ogni singolo file sorgente
36 una licenza permissiva come BSD, MIT eccetera.
48 aggiungere il corrispondente blocco di testo come commento in testa a detto
66 licenze SPDX assieme al rispettivo testo come mostrato in
74 L'identificativo di licenza SPDX dev'essere posizionato come prima riga
77 come prima riga '#!PATH_TO_INTERPRETER'. Per questi script l'identificativo
107 SPDX della licenza come indicato nella lista di licenze SPDX, oppure la
113 Gli identificativi di licenza per licenze come la [L]GPL che si avvalgono
167 Le licenze attualmente in uso, così come le licenze aggiunte al kernel, possono
[all …]
|
| D | volatile-considered-harmful.rst | 12 essere cambiate al di fuori dal thread di esecuzione corrente; come risultato,
15 *volatile* come una variabile atomica di facile utilizzo, ma non è così.
27 Come *volatile*, le primitive del kernel che rendono sicuro l'accesso ai dati
45 in attesa del lock. Gli spinlock agiscono come barriere di sincronizzazione
49 spin_lock(), che agisce come una barriera di sincronizzazione, gli imporrà di
52 Se il dato condiviso fosse stato dichiarato come *volatile*, la
78 o cedere il passo ad un processore hyperthreaded gemello; funziona anche come
111 visto come un baco e porterà a verifiche aggiuntive. Gli sviluppatori tentati
|
| D | botching-up-ioctls.rst | 6 (Come evitare di) Raffazzonare delle ioctl
23 focalizzano sui tecnicismi e non sulla visione d'insieme, come le discussioni
36 definiti nello spazio utente, il kernel definisce alcuni tipi speciali, come:
54 vostro codice perché questo riduce le verifiche che strumenti come sparse
135 allora implementate una scadenza oppure come ultima spiaggia una rete di
155 derivano da domini temporali diversi come il vostro orologio di sistema
175 qualcosa di molto lento come il contatore di *frame*. Con la giacca da
209 oggetti specifici di dispositivo, come i connettori, condividono uno spazio
219 ma considerate l'idea di usare il numero di inode come identificatore per i
220 descrittori di file condivisi - che poi è come si distinguono i veri file.
[all …]
|
| D | email-clients.rst | 20 stessi. Salvatela come testo includendo tutte le intestazioni. Poi eseguite
29 come testo integrante del messaggio. Alcuni manutentori accettano gli
31 impostato come ``text/plain``. Tuttavia, generalmente gli allegati non sono
79 suggerimenti non sono da considerarsi come un riassunto di una configurazione
149 Come soluzione aggiuntiva potreste personalizzare la vostra barra degli
163 inserite come testo del messaggio le rende più difficili da estrarre dalla loro
166 Se dovete assolutamente inviare delle patch come allegati invece di integrarle
170 l'allegato sia più leggibile venendo visualizzato come parte del messaggio.
172 Per salvare le patch inviate come parte di un messaggio, selezionate il
174 :menuselection:`Salva come`. Se il messaggio fu ben preparato, allora potrete
[all …]
|
| D | adding-syscalls.rst | 12 nuove chiamate di sistema al kernel Linux; questo è da considerarsi come
13 un'aggiunta ai soliti consigli su come proporre nuove modifiche
38 come chiamate :manpage:`ioctl(2)`, il che potrebbe portare ad un'API in
45 essere sempre vero (per esempio, in ambienti come namespace/sandbox/chroot).
57 Come per :manpage:`fcntl(2)`, questa chiamata di sistema è un complesso
153 Questo permette più flessibilità su come lo spazio utente specificherà il file
167 per descrivere uno scostamento all'interno di un file, usate ``loff_t`` come
173 (verificato con una chiamata a ``capable()``), come descritto nella pagina man
210 scritta nell'email di presentazione, oppure come modifica vera e propria
213 Le proposte di nuove chiamate di sistema, come ogni altro modifica all'API del
[all …]
|
| D | coding-style.rst | 112 Come limite di riga si preferiscono le 80 colonne.
125 Tuttavia, non spezzettate mai le stringhe visibili agli utenti come i
136 come mostratoci dai profeti Kernighan e Ritchie, è quello di
180 nell'espressione if-else, come questo:
254 linguaggio non lo richiede; come ``sizeof info`` dopo aver dichiarato
288 binari o ternari, come i seguenti::
325 nomi graziosi come ThisVariableIsATemporaryCounter. Un programmatore C
334 dei nomi descrittivi, così come le funzioni globali. Se avete una funzione
355 Per favore non usate cose come ``vps_t``.
382 una bella cosa. Il motivo per cui abbiamo cose come pte_t eccetera è
[all …]
|
| D | 2.Process.rst | 8 Come funziona il processo di sviluppo
15 lo sviluppo più agevole. È richiesta una solida conoscenza di come tale
68 amichevole. Come regola generale: se vi perdete la finestra di inclusione per
162 come una patch viene inserita nel kernel. Ciò che segue è un'introduzione
169 della modifica - e come verranno soddisfatti. Il lavoro di progettazione
223 Come le modifiche finiscono nel Kernel
247 Strumenti come git (e affini come quilt o mercurial) permettono ai manutentori
258 È chiaro che, qualche volta, guardi più attentamente. Ma, come regola
267 i due o tre collegamenti. Questo processo è conosciuto come
271 Chiaramente, in un sistema come questo, l'inserimento delle patch all'interno
[all …]
|
| /kernel/linux/linux-5.10/Documentation/translations/it_IT/process/ |
| D | 5.Posting.rst | 67 Come regola generale, pensarci un po' di più prima di inviare il codice
79 Come regola generale, una patch dovrebbe basarsi sul ramo principale attuale
80 così come lo si trova nei sorgenti git di Linus. Quando vi basate sul ramo
92 Solo le modifiche più semplici dovrebbero essere preparate come una singola
93 patch; tutto il resto dovrebbe essere preparato come una serie logica di
95 passano molto tempo nel capire come farlo in modo che piaccia alla comunità.
100 come quella che trovate nel vostro sistema di controllo di versione.
106 - Ogni modifica logicamente indipendente dovrebbe essere preparata come una
126 difficile così come quella di chi s'impegna nel nobile lavoro di
136 come una serie di patch, ma di lasciare questa infrastruttura inutilizzata
[all …]
|
| D | howto.rst | 8 Come partecipare allo sviluppo del kernel Linux
12 Esso contiene le istruzioni su come diventare uno sviluppatore
13 del kernel Linux e spiega come lavorare con la comunità di
24 Dunque, volete imparare come diventare sviluppatori del kernel Linux?
29 su come lavorare con la comunità. Il documento cercherà, inoltre,
57 Tenete a mente che state cercando di apprendere come lavorare con la comunità
82 insegneranno come interagire con la comunità del kernel. Quando nuove
84 relativi file di documentatione che spiegano come usarele.
115 Questo file descrive dettagliatamente come creare ed inviare una patch
126 Altre ottime descrizioni di come creare buone patch sono:
[all …]
|
| D | 7.AdvancedTopics.rst | 11 A questo punto, si spera, dovreste avere un'idea su come funziona il processo
33 documento al riguardo. Invece, qui ci concentriamo in particolare su come
46 base solida su come funziona git. Uno sviluppatore che sappia usare git
50 (come ``rebase``) è altrettanto utile. Git ha i propri concetti e la propria
80 riscritta come se fosse stata scritta in cima al ramo principale di oggi,
94 la storia che avete esposto ad altri, generalmente, dovrebbe essere vista come
121 può essere utile; questo strumento si ricorda come i conflitti di *merge*
124 Una delle lamentele più grosse e ricorrenti sull'uso di strumenti come git
169 migliore di imparare come programmare per il kernel che guardare il codice
179 i commenti come domande e non come critiche. Chiedere "Come viene rilasciato
|
| D | license-rules.rst | 16 aggiunge eccezione per le chiamate di sistema come descritto in
19 Questo documento fornisce una descrizione su come ogni singolo file sorgente
36 una licenza permissiva come BSD, MIT eccetera.
48 aggiungere il corrispondente blocco di testo come commento in testa a detto
66 licenze SPDX assieme al rispettivo testo come mostrato in
74 L'identificativo di licenza SPDX dev'essere posizionato come prima riga
77 come prima riga '#!PATH_TO_INTERPRETER'. Per questi script l'identificativo
107 SPDX della licenza come indicato nella lista di licenze SPDX, oppure la
113 Gli identificativi di licenza per licenze come la [L]GPL che si avvalgono
167 Le licenze attualmente in uso, così come le licenze aggiunte al kernel, possono
[all …]
|
| D | volatile-considered-harmful.rst | 12 essere cambiate al di fuori dal thread di esecuzione corrente; come risultato,
15 *volatile* come una variabile atomica di facile utilizzo, ma non è così.
27 Come *volatile*, le primitive del kernel che rendono sicuro l'accesso ai dati
45 in attesa del lock. Gli spinlock agiscono come barriere di sincronizzazione
49 spin_lock(), che agisce come una barriera di sincronizzazione, gli imporrà di
52 Se il dato condiviso fosse stato dichiarato come *volatile*, la
78 o cedere il passo ad un processore hyperthreaded gemello; funziona anche come
111 visto come un baco e porterà a verifiche aggiuntive. Gli sviluppatori tentati
|
| D | email-clients.rst | 20 stessi. Salvatela come testo includendo tutte le intestazioni. Poi eseguite
29 come testo integrante del messaggio. Alcuni manutentori accettano gli
31 impostato come ``text/plain``. Tuttavia, generalmente gli allegati non sono
74 suggerimenti non sono da considerarsi come un riassunto di una configurazione
144 Come soluzione aggiuntiva potreste personalizzare la vostra barra degli
158 inserite come testo del messaggio le rende più difficili da estrarre dalla loro
161 Se dovete assolutamente inviare delle patch come allegati invece di integrarle
165 l'allegato sia più leggibile venendo visualizzato come parte del messaggio.
167 Per salvare le patch inviate come parte di un messaggio, selezionate il
169 :menuselection:`Salva come`. Se il messaggio fu ben preparato, allora potrete
[all …]
|
| D | submitting-patches.rst | 18 maggiori dettagli su come funziona il processo di sviluppo del kernel leggete
48 Esiste ancora la possibilità di scaricare un rilascio del kernel come archivio
49 tar (come descritto in una delle prossime sezioni), ma questa è la via più
59 Tutte le modifiche al kernel Linux avvengono mediate patch, come descritte
61 crearla nel formato "unified diff", come l'argomento ``-u`` di
140 Una volta che il problema è chiaro, descrivete come lo risolvete andando
143 comporti come descritto.
147 ``git``, come un "commit log". Leggete :ref:`it_explicit_in_reply_to`.
164 xyzzy to do frotz", come se steste dando ordini al codice di cambiare il suo
203 i risultati dei comandi ``git log`` o ``git show`` come nell'esempio
[all …]
|
| D | adding-syscalls.rst | 12 nuove chiamate di sistema al kernel Linux; questo è da considerarsi come
13 un'aggiunta ai soliti consigli su come proporre nuove modifiche
38 come chiamate :manpage:`ioctl(2)`, il che potrebbe portare ad un'API in
45 essere sempre vero (per esempio, in ambienti come namespace/sandbox/chroot).
57 Come per :manpage:`fcntl(2)`, questa chiamata di sistema è un complesso
153 Questo permette più flessibilità su come lo spazio utente specificherà il file
167 per descrivere uno scostamento all'interno di un file, usate ``loff_t`` come
173 (verificato con una chiamata a ``capable()``), come descritto nella pagina man
210 scritta nell'email di presentazione, oppure come modifica vera e propria
213 Le proposte di nuove chiamate di sistema, come ogni altro modifica all'API del
[all …]
|
| D | coding-style.rst | 103 non spezzettate mai le stringhe visibili agli utenti come i messaggi di
113 come mostratoci dai profeti Kernighan e Ritchie, è quello di
157 nell'espressione if-else, come questo:
231 linguaggio non lo richiede; come ``sizeof info`` dopo aver dichiarato
265 binari o ternari, come i seguenti::
302 nomi graziosi come ThisVariableIsATemporaryCounter. Un programmatore C
311 dei nomi descrittivi, così come le funzioni globali. Se avete una funzione
333 Per favore non usate cose come ``vps_t``.
360 una bella cosa. Il motivo per cui abbiamo cose come pte_t eccetera è
387 tipi standard come ``uint32_t``, alcune persone ne obiettano l'uso.
[all …]
|
| D | 2.Process.rst | 8 Come funziona il processo di sviluppo
15 lo sviluppo più agevole. È richiesta una solida conoscenza di come tale
68 amichevole. Come regola generale: se vi perdete la finestra di inclusione per
169 come una patch viene inserita nel kernel. Ciò che segue è un'introduzione
176 della modifica - e come verranno soddisfatti. Il lavoro di progettazione
230 Come le modifiche finiscono nel Kernel
254 Strumenti come git (e affini come quilt o mercurial) permettono ai manutentori
265 È chiaro che, qualche volta, guardi più attentamente. Ma, come regola
274 i due o tre collegamenti. Questo processo è conosciuto come
278 Chiaramente, in un sistema come questo, l'inserimento delle patch all'interno
[all …]
|
| /kernel/linux/linux-6.6/drivers/mfd/ |
| D | kempld-core.c | 403 /* PXT and COMe-cPC2 boards may require a second release */ in kempld_detect_device()
574 DMI_MATCH(DMI_BOARD_NAME, "COMe-bBD"),
582 DMI_MATCH(DMI_BOARD_NAME, "COMe-bBL6"),
590 DMI_MATCH(DMI_BOARD_NAME, "COMe-bDV7"),
598 DMI_MATCH(DMI_BOARD_NAME, "COMe-bHL6"),
606 DMI_MATCH(DMI_BOARD_NAME, "COMe-bKL6"),
614 DMI_MATCH(DMI_BOARD_NAME, "COMe-bSL6"),
622 DMI_MATCH(DMI_BOARD_NAME, "COMe-cAL"),
630 DMI_MATCH(DMI_BOARD_NAME, "COMe-cBL6"),
638 DMI_MATCH(DMI_BOARD_NAME, "COMe-cBW6"),
[all …]
|
| /kernel/linux/linux-5.10/drivers/mfd/ |
| D | kempld-core.c | 406 /* PXT and COMe-cPC2 boards may require a second release */ in kempld_detect_device()
579 DMI_MATCH(DMI_BOARD_NAME, "COMe-bBD"),
587 DMI_MATCH(DMI_BOARD_NAME, "COMe-bBL6"),
595 DMI_MATCH(DMI_BOARD_NAME, "COMe-bHL6"),
603 DMI_MATCH(DMI_BOARD_NAME, "COMe-bKL6"),
611 DMI_MATCH(DMI_BOARD_NAME, "COMe-bSL6"),
619 DMI_MATCH(DMI_BOARD_NAME, "COMe-cAL"),
627 DMI_MATCH(DMI_BOARD_NAME, "COMe-cBL6"),
635 DMI_MATCH(DMI_BOARD_NAME, "COMe-cBW6"),
643 DMI_MATCH(DMI_BOARD_NAME, "COMe-bIP2"),
[all …]
|
| /kernel/linux/linux-5.10/Documentation/translations/it_IT/ |
| D | index.rst | 59 Più in generale, la documentazione, come il kernel stesso, sono in
70 (GPLv2), come licenziare i singoli file; inoltre troverete i riferimenti al
100 Questi manuali contengono informazioni su come contribuire allo sviluppo
103 sviluppatori che contribuiscono ogni anno. Come in ogni grande comunità,
104 sapere come le cose vengono fatte renderà il processo di integrazione delle
117 Questi manuali forniscono dettagli su come funzionano i sottosistemi del
|
| /kernel/linux/linux-6.6/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/ |
| D | uncore-l3c.json | 40 …"BriefDescription": "Count of the number of read lines that come from this cluster of CPU core in …
41 …"PublicDescription": "Count of the number of read lines that come from this cluster of CPU core in…
47 …"BriefDescription": "Count of the number of write lines that come from this cluster of CPU core in…
48 …"PublicDescription": "Count of the number of write lines that come from this cluster of CPU core i…
|
| /kernel/linux/linux-5.10/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/ |
| D | uncore-l3c.json | 40 …"BriefDescription": "Count of the number of read lines that come from this cluster of CPU core in …
41 …"PublicDescription": "Count of the number of read lines that come from this cluster of CPU core in…
47 …"BriefDescription": "Count of the number of write lines that come from this cluster of CPU core in…
48 …"PublicDescription": "Count of the number of write lines that come from this cluster of CPU core i…
|