diff options
Diffstat (limited to 'Documentation/translations')
45 files changed, 1690 insertions, 239 deletions
diff --git a/Documentation/translations/it_IT/admin-guide/README.rst b/Documentation/translations/it_IT/admin-guide/README.rst index b37166817842..c874586a9af9 100644 --- a/Documentation/translations/it_IT/admin-guide/README.rst +++ b/Documentation/translations/it_IT/admin-guide/README.rst @@ -4,7 +4,7 @@ .. _it_readme: -Rilascio del kernel Linux 5.x <http://kernel.org/> +Rilascio del kernel Linux 6.x <http://kernel.org/> =================================================== .. warning:: diff --git a/Documentation/translations/it_IT/doc-guide/kernel-doc.rst b/Documentation/translations/it_IT/doc-guide/kernel-doc.rst index 78082281acf9..5cece223b46b 100644 --- a/Documentation/translations/it_IT/doc-guide/kernel-doc.rst +++ b/Documentation/translations/it_IT/doc-guide/kernel-doc.rst @@ -3,6 +3,8 @@ .. note:: Per leggere la documentazione originale in inglese: :ref:`Documentation/doc-guide/index.rst <doc_guide>` +.. title:: Commenti in kernel-doc + .. _it_kernel_doc: ================================= diff --git a/Documentation/translations/it_IT/doc-guide/sphinx.rst b/Documentation/translations/it_IT/doc-guide/sphinx.rst index 64528790dc34..1f513bc33618 100644 --- a/Documentation/translations/it_IT/doc-guide/sphinx.rst +++ b/Documentation/translations/it_IT/doc-guide/sphinx.rst @@ -151,7 +151,8 @@ Ovviamente, per generare la documentazione, Sphinx (``sphinx-build``) dev'essere installato. Se disponibile, il tema *Read the Docs* per Sphinx verrà utilizzato per ottenere una documentazione HTML più gradevole. Per la documentazione in formato PDF, invece, avrete bisogno di ``XeLaTeX` -e di ``convert(1)`` disponibile in ImageMagick (https://www.imagemagick.org). +e di ``convert(1)`` disponibile in ImageMagick +(https://www.imagemagick.org). \ [#ink]_ Tipicamente, tutti questi pacchetti sono disponibili e pacchettizzati nelle distribuzioni Linux. @@ -162,9 +163,20 @@ la generazione potete usare il seguente comando ``make SPHINXOPTS=-v htmldocs``. Potete anche personalizzare l'ouptut html passando un livello aggiuntivo DOCS_CSS usando la rispettiva variabile d'ambiente ``DOCS_CSS``. +La variable make ``SPHINXDIRS`` è utile quando si vuole generare solo una parte +della documentazione. Per esempio, si possono generare solo di documenti in +``Documentation/doc-guide`` eseguendo ``make SPHINXDIRS=doc-guide htmldocs``. La +sezione dedicata alla documentazione di ``make help`` vi mostrerà quali sotto +cartelle potete specificare. + Potete eliminare la documentazione generata tramite il comando ``make cleandocs``. +.. [#ink] Avere installato anche ``inkscape(1)`` dal progetto Inkscape () + potrebbe aumentare la qualità delle immagini che verranno integrate + nel documento PDF, specialmente per quando si usando rilasci del + kernel uguali o superiori a 5.18 + Scrivere la documentazione ========================== diff --git a/Documentation/translations/it_IT/index.rst b/Documentation/translations/it_IT/index.rst index e80a3097aa57..fc5f39814e83 100644 --- a/Documentation/translations/it_IT/index.rst +++ b/Documentation/translations/it_IT/index.rst @@ -1,3 +1,5 @@ +.. SPDX-License-Identifier: GPL-2.0 + .. _it_linux_doc: =================== @@ -67,75 +69,68 @@ I miglioramenti alla documentazione sono sempre i benvenuti; per cui, se vuoi aiutare, iscriviti alla lista di discussione linux-doc presso vger.kernel.org. -Documentazione sulla licenza dei sorgenti ------------------------------------------ - -I seguenti documenti descrivono la licenza usata nei sorgenti del kernel Linux -(GPLv2), come licenziare i singoli file; inoltre troverete i riferimenti al -testo integrale della licenza. +Lavorare con la comunità di sviluppo +------------------------------------ -* :ref:`it_kernel_licensing` +Le guide fondamentali per l'interazione con la comunità di sviluppo del kernel e +su come vedere il proprio lavoro integrato. -Documentazione per gli utenti ------------------------------ - -I seguenti manuali sono scritti per gli *utenti* del kernel - ovvero, -coloro che cercano di farlo funzionare in modo ottimale su un dato sistema - -.. warning:: +.. toctree:: + :maxdepth: 1 - TODO ancora da tradurre + process/development-process + process/submitting-patches + Code of conduct <process/code-of-conduct> + All development-process docs <process/index> -Documentazione per gli sviluppatori di applicazioni ---------------------------------------------------- -Il manuale delle API verso lo spazio utente è una collezione di documenti -che descrivono le interfacce del kernel viste dagli sviluppatori -di applicazioni. +Manuali sull'API interna +------------------------ -.. warning:: +Di seguito una serie di manuali per gli sviluppatori che hanno bisogno di +interfacciarsi con il resto del kernel. - TODO ancora da tradurre +.. toctree:: + :maxdepth: 1 + core-api/index -Introduzione allo sviluppo del kernel -------------------------------------- +Strumenti e processi per lo sviluppo +------------------------------------ -Questi manuali contengono informazioni su come contribuire allo sviluppo -del kernel. -Attorno al kernel Linux gira una comunità molto grande con migliaia di -sviluppatori che contribuiscono ogni anno. Come in ogni grande comunità, -sapere come le cose vengono fatte renderà il processo di integrazione delle -vostre modifiche molto più semplice +Di seguito una serie di manuali contenenti informazioni utili a tutti gli +sviluppatori del kernel. .. toctree:: - :maxdepth: 2 + :maxdepth: 1 - process/index + process/license-rules doc-guide/index kernel-hacking/index -Documentazione della API del kernel ------------------------------------ +Documentazione per gli utenti +----------------------------- -Questi manuali forniscono dettagli su come funzionano i sottosistemi del -kernel dal punto di vista degli sviluppatori del kernel. Molte delle -informazioni contenute in questi manuali sono prese direttamente dai -file sorgenti, informazioni aggiuntive vengono aggiunte solo se necessarie -(o almeno ci proviamo — probabilmente *non* tutto quello che è davvero -necessario). +Di seguito una serie di manuali per gli *utenti* del kernel - ovvero coloro che +stanno cercando di farlo funzionare al meglio per un dato sistema, ma anche +coloro che stanno sviluppando applicazioni che sfruttano l'API verso lo +spazio-utente. -.. toctree:: - :maxdepth: 2 +Consultate anche `Linux man pages <https://www.kernel.org/doc/man-pages/>`_, che +vengono mantenuti separatamente dalla documentazione del kernel Linux + +Documentazione relativa ai firmware +----------------------------------- +Di seguito informazioni sulle aspettative del kernel circa i firmware. - core-api/index Documentazione specifica per architettura ----------------------------------------- -Questi manuali forniscono dettagli di programmazione per le diverse -implementazioni d'architettura. -.. warning:: +Documentazione varia +-------------------- - TODO ancora da tradurre +Ci sono documenti che sono difficili da inserire nell'attuale organizzazione +della documentazione; altri hanno bisogno di essere migliorati e/o convertiti +nel formato *ReStructured Text*; altri sono semplicamente troppo vecchi. diff --git a/Documentation/translations/it_IT/kernel-hacking/hacking.rst b/Documentation/translations/it_IT/kernel-hacking/hacking.rst index 560f1d0482d2..dd06bfc1a050 100644 --- a/Documentation/translations/it_IT/kernel-hacking/hacking.rst +++ b/Documentation/translations/it_IT/kernel-hacking/hacking.rst @@ -137,7 +137,7 @@ macro :c:func:`in_softirq()` (``include/linux/preempt.h``). .. warning:: State attenti che questa macro ritornerà un falso positivo - se :ref:`botton half lock <it_local_bh_disable>` è bloccato. + se :ref:`bottom half lock <it_local_bh_disable>` è bloccato. Alcune regole basilari ====================== diff --git a/Documentation/translations/it_IT/kernel-hacking/locking.rst b/Documentation/translations/it_IT/kernel-hacking/locking.rst index b8ecf41273c5..05d362b16bf0 100644 --- a/Documentation/translations/it_IT/kernel-hacking/locking.rst +++ b/Documentation/translations/it_IT/kernel-hacking/locking.rst @@ -1307,11 +1307,11 @@ se i dati vengono occasionalmente utilizzati da un contesto utente o da un'interruzione software. Il gestore d'interruzione non utilizza alcun *lock*, e tutti gli altri accessi verranno fatti così:: - spin_lock(&lock); + mutex_lock(&lock); disable_irq(irq); ... enable_irq(irq); - spin_unlock(&lock); + mutex_unlock(&lock); La funzione disable_irq() impedisce al gestore d'interruzioni d'essere eseguito (e aspetta che finisca nel caso fosse in esecuzione su diff --git a/Documentation/translations/it_IT/process/2.Process.rst b/Documentation/translations/it_IT/process/2.Process.rst index 62826034e0b2..25cd00351c03 100644 --- a/Documentation/translations/it_IT/process/2.Process.rst +++ b/Documentation/translations/it_IT/process/2.Process.rst @@ -136,18 +136,11 @@ Quindi, per esempio, la storia del kernel 5.2 appare così (anno 2019): La 5.2.21 fu l'aggiornamento finale per la versione 5.2. Alcuni kernel sono destinati ad essere kernel a "lungo termine"; questi -riceveranno assistenza per un lungo periodo di tempo. Al momento in cui -scriviamo, i manutentori dei kernel stabili a lungo termine sono: - - ====== ================================ ========================================== - 3.16 Ben Hutchings (kernel stabile molto più a lungo termine) - 4.4 Greg Kroah-Hartman e Sasha Levin (kernel stabile molto più a lungo termine) - 4.9 Greg Kroah-Hartman e Sasha Levin - 4.14 Greg Kroah-Hartman e Sasha Levin - 4.19 Greg Kroah-Hartman e Sasha Levin - 5.4i Greg Kroah-Hartman e Sasha Levin - ====== ================================ ========================================== +riceveranno assistenza per un lungo periodo di tempo. Consultate il seguente +collegamento per avere la lista delle versioni attualmente supportate e i +relativi manutentori: + https://www.kernel.org/category/releases.html Questa selezione di kernel di lungo periodo sono puramente dovuti ai loro manutentori, alla loro necessità e al tempo per tenere aggiornate proprio diff --git a/Documentation/translations/it_IT/process/7.AdvancedTopics.rst b/Documentation/translations/it_IT/process/7.AdvancedTopics.rst index cc1cff5d23ae..dffd813a0910 100644 --- a/Documentation/translations/it_IT/process/7.AdvancedTopics.rst +++ b/Documentation/translations/it_IT/process/7.AdvancedTopics.rst @@ -35,9 +35,9 @@ git è parte del processo di sviluppo del kernel. Gli sviluppatori che desiderassero diventare agili con git troveranno più informazioni ai seguenti indirizzi: - http://git-scm.com/ + https://git-scm.com/ - http://www.kernel.org/pub/software/scm/git/docs/user-manual.html + https://www.kernel.org/pub/software/scm/git/docs/user-manual.html e su varie guide che potrete trovare su internet. @@ -63,7 +63,7 @@ eseguire git-daemon è relativamente semplice . Altrimenti, iniziano a svilupparsi piattaforme che offrono spazi pubblici, e gratuiti (Github, per esempio). Gli sviluppatori permanenti possono ottenere un account su kernel.org, ma non è proprio facile da ottenere; per maggiori informazioni -consultate la pagina web http://kernel.org/faq/. +consultate la pagina web https://kernel.org/faq/. In git è normale avere a che fare con tanti rami. Ogni linea di sviluppo può essere separata in "rami per argomenti" e gestiti indipendentemente. @@ -137,7 +137,7 @@ vostri rami. Citando Linus facendo, e ho bisogno di fidarmi *senza* dover passare tutte le modifiche manualmente una per una. -(http://lwn.net/Articles/224135/). +(https://lwn.net/Articles/224135/). Per evitare queste situazioni, assicuratevi che tutte le patch in un ramo siano strettamente correlate al tema delle modifiche; un ramo "driver fixes" diff --git a/Documentation/translations/it_IT/process/botching-up-ioctls.rst b/Documentation/translations/it_IT/process/botching-up-ioctls.rst new file mode 100644 index 000000000000..91732cdf808a --- /dev/null +++ b/Documentation/translations/it_IT/process/botching-up-ioctls.rst @@ -0,0 +1,249 @@ +.. include:: ../disclaimer-ita.rst + +:Original: Documentation/process/botching-up-ioctls.rst + +========================================== +(Come evitare di) Raffazzonare delle ioctl +========================================== + +Preso da: https://blog.ffwll.ch/2013/11/botching-up-ioctls.html + +Scritto da : Daniel Vetter, Copyright © 2013 Intel Corporation + +Una cosa che gli sviluppatori del sottosistema grafico del kernel Linux hanno +imparato negli ultimi anni è l'inutilità di cercare di creare un'interfaccia +unificata per gestire la memoria e le unità esecutive di diverse GPU. Dunque, +oggigiorno ogni driver ha il suo insieme di ioctl per allocare memoria ed +inviare dei programmi alla GPU. Il che è va bene dato che non c'è più un insano +sistema che finge di essere generico, ma al suo posto ci sono interfacce +dedicate. Ma al tempo stesso è più facile incasinare le cose. + +Per evitare di ripetere gli stessi errori ho preso nota delle lezioni imparate +mentre raffazzonavo il driver drm/i915. La maggior parte di queste lezioni si +focalizzano sui tecnicismi e non sulla visione d'insieme, come le discussioni +riguardo al modo migliore per implementare una ioctl per inviare compiti alla +GPU. Probabilmente, ogni sviluppatore di driver per GPU dovrebbe imparare queste +lezioni in autonomia. + + +Prerequisiti +------------ + +Prima i prerequisiti. Seguite i seguenti suggerimenti se non volete fallire in +partenza e ritrovarvi ad aggiungere un livello di compatibilità a 32-bit. + +* Usate solamente interi a lunghezza fissa. Per evitare i conflitti coi tipi + definiti nello spazio utente, il kernel definisce alcuni tipi speciali, come: + ``__u32``, ``__s64``. Usateli. + +* Allineate tutto alla lunghezza naturale delle piattaforma in uso e riempite + esplicitamente i vuoti. Non necessariamente le piattaforme a 32-bit allineano + i valori a 64-bit rispettandone l'allineamento, ma le piattaforme a 64-bit lo + fanno. Dunque, per farlo correttamente in entrambe i casi dobbiamo sempre + riempire i vuoti. + +* Se una struttura dati contiene valori a 64-bit, allora fate si che la sua + dimensione sia allineata a 64-bit, altrimenti la sua dimensione varierà su + sistemi a 32-bit e 64-bit. Avere una dimensione differente causa problemi + quando si passano vettori di strutture dati al kernel, o quando il kernel + effettua verifiche sulla dimensione (per esempio il sistema drm lo fa). + +* I puntatori sono di tipo ``__u64``, con un *cast* da/a ``uintptr_t`` da lato + spazio utente e da/a ``void __user *`` nello spazio kernel. Sforzatevi il più + possibile per non ritardare la conversione, o peggio maneggiare ``__u64`` nel + vostro codice perché questo riduce le verifiche che strumenti come sparse + possono effettuare. La macro u64_to_user_ptr() può essere usata nel kernel + per evitare avvisi riguardo interi e puntatori di dimensioni differenti. + + +Le Basi +------- + +Con la gioia d'aver evitato un livello di compatibilità, possiamo ora dare uno +sguardo alle basi. Trascurare questi punti renderà difficile la gestione della +compatibilità all'indietro ed in avanti. E dato che sbagliare al primo colpo è +garantito, dovrete rivisitare il codice o estenderlo per ogni interfaccia. + +* Abbiate un modo chiaro per capire dallo spazio utente se una nuova ioctl, o + l'estensione di una esistente, sia supportata dal kernel in esecuzione. Se non + potete fidarvi del fatto che un vecchio kernel possa rifiutare correttamente + un nuovo *flag*, modalità, o ioctl, (probabilmente perché avevate raffazzonato + qualcosa nel passato) allora dovrete implementare nel driver un meccanismo per + notificare quali funzionalità sono supportate, o in alternativa un numero di + versione. + +* Abbiate un piano per estendere le ioctl con nuovi *flag* o campi alla fine di + una struttura dati. Il sistema drm verifica la dimensione di ogni ioctl in + arrivo, ed estende con zeri ogni incongruenza fra kernel e spazio utente. + Questo aiuta, ma non è una soluzione completa dato che uno spazio utente nuovo + su un kernel vecchio non noterebbe che i campi nuovi alla fine della struttura + vengono ignorati. Dunque, anche questo avrà bisogno di essere notificato dal + driver allo spazio utente. + +* Verificate tutti i campi e *flag* inutilizzati ed i riempimenti siano a 0, + altrimenti rifiutare la ioctl. Se non lo fate il vostro bel piano per + estendere le ioctl andrà a rotoli dato che qualcuno userà delle ioctl con + strutture dati con valori casuali dallo stack nei campi inutilizzati. Il che + si traduce nell'avere questi campi nell'ABI, e la cui unica utilità sarà + quella di contenere spazzatura. Per questo dovrete esplicitamente riempire i + vuoti di tutte le vostre strutture dati, anche se non le userete in un + vettore. Il riempimento fatto dal compilatore potrebbe contenere valori + casuali. + +* Abbiate un semplice codice di test per ognuno dei casi sopracitati. + + +Divertirsi coi percorsi d'errore +-------------------------------- + +Oggigiorno non ci sono più scuse rimaste per permettere ai driver drm di essere +sfruttati per diventare root. Questo significa che dobbiamo avere una completa +validazione degli input e gestire in modo robusto i percorsi - tanto le GPU +moriranno comunque nel più strano dei casi particolari: + + * Le ioctl devono verificare l'overflow dei vettori. Inoltre, per i valori + interi si devono verificare *overflow*, *underflow*, e *clamping*. Il + classico esempio è l'inserimento direttamente nell'hardware di valori di + posizionamento di un'immagine *sprite* quando l'hardware supporta giusto 12 + bit, o qualcosa del genere. Tutto funzionerà finché qualche strano *display + server* non decide di preoccuparsi lui stesso del *clamping* e il cursore + farà il giro dello schermo. + + * Avere un test semplice per ogni possibile fallimento della vostra ioctl. + Verificate che il codice di errore rispetti le aspettative. Ed infine, + assicuratevi che verifichiate un solo percorso sbagliato per ogni sotto-test + inviando comunque dati corretti. Senza questo, verifiche precedenti + potrebbero rigettare la ioctl troppo presto, impedendo l'esecuzione del + codice che si voleva effettivamente verificare, rischiando quindi di + mascherare bachi e regressioni. + + * Fate si che tutte le vostre ioctl siano rieseguibili. Prima di tutto X adora + i segnali; secondo questo vi permetterà di verificare il 90% dei percorsi + d'errore interrompendo i vostri test con dei segnali. Grazie all'amore di X + per i segnali, otterrete gratuitamente un eccellente copertura di base per + tutti i vostri percorsi d'errore. Inoltre, siate consistenti sul modo di + gestire la riesecuzione delle ioctl - per esempio, drm ha una piccola + funzione di supporto `drmIoctl` nella sua librerie in spazio utente. Il + driver i915 l'abbozza con l'ioctl `set_tiling`, ed ora siamo inchiodati per + sempre con una semantica arcana sia nel kernel che nello spazio utente. + + + * Se non potete rendere un pezzo di codice rieseguibile, almeno rendete + possibile la sua interruzione. Le GPU moriranno e i vostri utenti non vi + apprezzeranno affatto se tenete in ostaggio il loro scatolotto (mediante un + processo X insopprimibile). Se anche recuperare lo stato è troppo complicato, + allora implementate una scadenza oppure come ultima spiaggia una rete di + sicurezza per rilevare situazioni di stallo quando l'hardware da di matto. + + * Preparate dei test riguardo ai casi particolarmente estremi nel codice di + recupero del sistema - è troppo facile create uno stallo fra il vostro codice + anti-stallo e un processo scrittore. + + +Tempi, attese e mancate scadenze +-------------------------------- + +Le GPU fanno quasi tutto in modo asincrono, dunque dobbiamo regolare le +operazioni ed attendere quelle in sospeso. Questo è davvero difficile; al +momento nessuna delle ioctl supportante dal driver drm/i915 riesce a farlo +perfettamente, il che significa che qui ci sono ancora una valanga di lezioni da +apprendere. + + * Per fare riferimento al tempo usate sempre ``CLOCK_MONOTONIC``. Oggigiorno + questo è quello che viene usato di base da alsa, drm, e v4l. Tuttavia, + lasciate allo spazio utente la possibilità di capire quali *timestamp* + derivano da domini temporali diversi come il vostro orologio di sistema + (fornito dal kernel) oppure un contatore hardware indipendente da qualche + parte. Gli orologi divergeranno, ma con questa informazione gli strumenti di + analisi delle prestazioni possono compensare il problema. Se il vostro spazio + utente può ottenere i valori grezzi degli orologi, allora considerate di + esporre anch'essi. + + * Per descrivere il tempo, usate ``__s64`` per i secondi e ``__u64`` per i + nanosecondi. Non è il modo migliore per specificare il tempo, ma è + praticamente uno standard. + + * Verificate che gli input di valori temporali siano normalizzati, e se non lo + sono scartateli. Fate attenzione perché la struttura dati ``struct ktime`` + del kernel usa interi con segni sia per i secondi che per i nanosecondi. + + * Per le scadenze (*timeout*) usate valori temporali assoluti. Se siete dei + bravi ragazzi e avete reso la vostra ioctl rieseguibile, allora i tempi + relativi tendono ad essere troppo grossolani e a causa degli arrotondamenti + potrebbero estendere in modo indefinito i tempi di attesa ad ogni + riesecuzione. Particolarmente vero se il vostro orologio di riferimento è + qualcosa di molto lento come il contatore di *frame*. Con la giacca da + avvocato delle specifiche diremmo che questo non è un baco perché tutte le + scadenze potrebbero essere estese - ma sicuramente gli utenti vi odieranno + quando le animazioni singhiozzano. + + * Considerate l'idea di eliminare tutte le ioctl sincrone con scadenze, e di + sostituirle con una versione asincrona il cui stato può essere consultato + attraverso il descrittore di file mediante ``poll``. Questo approccio si + sposa meglio in un applicazione guidata dagli eventi. + + * Sviluppate dei test per i casi estremi, specialmente verificate che i valori + di ritorno per gli eventi già completati, le attese terminate con successo, e + le attese scadute abbiano senso e servano ai vostri scopi. + + +Non perdere risorse +------------------- +Nel suo piccolo il driver drm implementa un sistema operativo specializzato per +certe GPU. Questo significa che il driver deve esporre verso lo spazio +utente tonnellate di agganci per accedere ad oggetti e altre risorse. Farlo +correttamente porterà con se alcune insidie: + + * Collegate sempre la vita di una risorsa creata dinamicamente, a quella del + descrittore di file. Considerate una mappatura 1:1 se la vostra risorsa + dev'essere condivisa fra processi - passarsi descrittori di file sul socket + unix semplifica la gestione anche per lo spazio utente. + + * Dev'esserci sempre Il supporto ``O_CLOEXEC``. + + * Assicuratevi di avere abbastanza isolamento fra utenti diversi. Di base + impostate uno spazio dei nomi riservato per ogni descrittore di file, il che + forzerà ogni condivisione ad essere esplicita. Usate uno spazio più globale + per dispositivo solo se gli oggetti sono effettivamente unici per quel + dispositivo. Un controesempio viene dall'interfaccia drm modeset, dove + oggetti specifici di dispositivo, come i connettori, condividono uno spazio + dei nomi con oggetti per il *framebuffer*, ma questi non sono per niente + condivisi. Uno spazio separato, privato di base, per i *framebuffer* sarebbe + stato meglio. + + * Pensate all'identificazione univoca degli agganci verso lo spazio utente. Per + esempio, per la maggior parte dei driver drm, si considera fallace la doppia + sottomissione di un oggetto allo stesso comando ioctl. Ma per evitarlo, se + gli oggetti sono condivisibili, lo spazio utente ha bisogno di sapere se il + driver ha importato un oggetto da un altro processo. Non l'ho ancora provato, + ma considerate l'idea di usare il numero di inode come identificatore per i + descrittori di file condivisi - che poi è come si distinguono i veri file. + Sfortunatamente, questo richiederebbe lo sviluppo di un vero e proprio + filesystem virtuale nel kernel. + + +Ultimo, ma non meno importante +------------------------------ + +Non tutti i problemi si risolvono con una nuova ioctl: + +* Pensateci su due o tre volte prima di implementare un'interfaccia privata per + un driver. Ovviamente è molto più veloce seguire questa via piuttosto che + buttarsi in lunghe discussioni alla ricerca di una soluzione più generica. Ed + a volte un'interfaccia privata è quello che serve per sviluppare un nuovo + concetto. Ma alla fine, una volta che c'è un'interfaccia generica a + disposizione finirete per mantenere due interfacce. Per sempre. + +* Considerate interfacce alternative alle ioctl. Gli attributi sysfs sono molto + meglio per impostazioni che sono specifiche di un dispositivo, o per + sotto-oggetti con una vita piuttosto statica (come le uscite dei connettori in + drm con tutti gli attributi per la sovrascrittura delle rilevazioni). O magari + solo il vostro sistema di test ha bisogno di una certa interfaccia, e allora + debugfs (che non ha un'interfaccia stabile) sarà la soluzione migliore. + +Per concludere. Questo gioco consiste nel fare le cose giuste fin da subito, +dato che se il vostro driver diventa popolare e la piattaforma hardware longeva +finirete per mantenere le vostre ioctl per sempre. Potrete tentare di deprecare +alcune orribili ioctl, ma ci vorranno anni per riuscirci effettivamente. E +ancora, altri anni prima che sparisca l'ultimo utente capace di lamentarsi per +una regressione. diff --git a/Documentation/translations/it_IT/process/changes.rst b/Documentation/translations/it_IT/process/changes.rst index 10e0ef9c34b7..473ec2cc558e 100644 --- a/Documentation/translations/it_IT/process/changes.rst +++ b/Documentation/translations/it_IT/process/changes.rst @@ -35,6 +35,7 @@ PC Card, per esempio, probabilmente non dovreste preoccuparvi di pcmciautils. GNU C 5.1 gcc --version Clang/LLVM (optional) 11.0.0 clang --version GNU make 3.81 make --version +bash 4.2 bash --version binutils 2.23 ld -v flex 2.5.35 flex --version bison 2.0 bison --version @@ -88,6 +89,11 @@ Make Per compilare il kernel vi servirà GNU make 3.81 o successivo. +Bash +---- +Per generare il kernel vengono usati alcuni script per bash. +Questo richiede bash 4.2 o successivo. + Binutils -------- @@ -370,6 +376,11 @@ Make - <ftp://ftp.gnu.org/gnu/make/> +Bash +---- + +- <ftp://ftp.gnu.org/gnu/bash/> + Binutils -------- diff --git a/Documentation/translations/it_IT/process/email-clients.rst b/Documentation/translations/it_IT/process/email-clients.rst index de7d32f78246..970671cd91af 100644 --- a/Documentation/translations/it_IT/process/email-clients.rst +++ b/Documentation/translations/it_IT/process/email-clients.rst @@ -106,7 +106,7 @@ Funziona. Alcune persone riescono ad usarlo con successo per inviare le patch. Per inserire una patch usate :menuselection:`Messaggio-->Inserisci file` (:kbd:`CTRL-I`) oppure un editor esterno. -Se la patch che avete inserito dev'essere modificata usato la finestra di +Se la patch che avete inserito dev'essere modificata usando la finestra di scrittura di Claws, allora assicuratevi che l'"auto-interruzione" sia disabilitata :menuselection:`Configurazione-->Preferenze-->Composizione-->Interruzione riga`. @@ -288,37 +288,62 @@ Thunderbird (GUI) Thunderbird è un clone di Outlook a cui piace maciullare il testo, ma esistono modi per impedirglielo. +Dopo la configurazione, inclusa l'installazione delle estenzioni, dovrete +riavviare Thunderbird. + - permettere l'uso di editor esterni: + La cosa più semplice da fare con Thunderbird e le patch è quello di usare - l'estensione "external editor" e di usare il vostro ``$EDITOR`` preferito per - leggere/includere patch nel vostro messaggio. Per farlo, scaricate ed - installate l'estensione e aggiungete un bottone per chiamarla rapidamente - usando :menuselection:`Visualizza-->Barra degli strumenti-->Personalizza...`; - una volta fatto potrete richiamarlo premendo sul bottone mentre siete nella - finestra :menuselection:`Scrivi` - - Tenete presente che "external editor" richiede che il vostro editor non - faccia alcun fork, in altre parole, l'editor non deve ritornare prima di - essere stato chiuso. Potreste dover passare dei parametri aggiuntivi al - vostro editor oppure cambiargli la configurazione. Per esempio, usando - gvim dovrete aggiungere l'opzione -f ``/usr/bin/gvim -f`` (Se il binario - si trova in ``/usr/bin``) nell'apposito campo nell'interfaccia di - configurazione di :menuselection:`external editor`. Se usate altri editor - consultate il loro manuale per sapere come configurarli. + estensioni che permettano di aprire il vostro editor preferito. + + Di seguito alcune estensioni che possono essere utili al caso. + + - "External Editor Revived" + + https://github.com/Frederick888/external-editor-revived + + https://addons.thunderbird.net/en-GB/thunderbird/addon/external-editor-revived/ + + L'estensione richiede l'installazione di "native messaging host". Date + un'occhiata alla seguente wiki: + https://github.com/Frederick888/external-editor-revived/wiki + + - "External Editor" + + https://github.com/exteditor/exteditor + + Per usarlo, scaricate ed installate l'applicazione. Poi aprite la finestra + :menuselection:`Scrivi` e a seguire aggiungete un bottone per eseguirlo + `Visualizza-->Barra degli strumenti-->Personalizza...`. Infine, premente + questo nuovo bottone tutte le volte che volete usare l'editor esterno. + + Tenete presente che "external editor" richiede che il vostro editor non + faccia alcun fork, in altre parole, l'editor non deve ritornare prima di + essere stato chiuso. Potreste dover passare dei parametri aggiuntivi al + vostro editor oppure cambiargli la configurazione. Per esempio, usando + gvim dovrete aggiungere l'opzione -f ``/usr/bin/gvim -f`` (Se il binario + si trova in ``/usr/bin``) nell'apposito campo nell'interfaccia di + configurazione di :menuselection:`external editor`. Se usate altri editor + consultate il loro manuale per sapere come configurarli.``)`` Per rendere l'editor interno un po' più sensato, fate così: -- Modificate le impostazioni di Thunderbird per far si che non usi - ``format=flowed``. Andate in :menuselection:`Modifica-->Preferenze-->Avanzate-->Editor di configurazione` +- Modificate le impostazioni di Thunderbird per far si che non usi ``format=flowed``! + Andate sulla finestra principale e cercate il bottone per il menu a tendina principale. + Poi :menuselection:`Modifica-->Preferenze-->Avanzate-->Editor di configurazione` per invocare il registro delle impostazioni. -- impostate ``mailnews.send_plaintext_flowed`` a ``false`` + - impostate ``mailnews.send_plaintext_flowed`` a ``false`` -- impostate ``mailnews.wraplength`` da ``72`` a ``0`` + - impostate ``mailnews.wraplength`` da ``72`` a ``0`` -- :menuselection:`Visualizza-->Corpo del messaggio come-->Testo semplice` +- Non scrivete messaggi HTML! Andate sulla finestra principale ed aprite la + schermata :menuselection:`Menu principale-->Impostazioni account-->nome@unserver.ovunque-->Composizioni e indirizzi`. + Qui potrete disabilitare l'opzione "Componi i messaggi in HTML" -- :menuselection:`Visualizza-->Codifica del testo-->Unicode` +- Aprite i messaggi solo in formato testo! Andate sulla finestra principale e + selezionate + :menuselection:`Menu principale-->Visualizza-->Copro del messaggio come-->Testo semplice` TkRat (GUI) diff --git a/Documentation/translations/it_IT/process/index.rst b/Documentation/translations/it_IT/process/index.rst index 8d4e36a07ff4..25602c1a97d1 100644 --- a/Documentation/translations/it_IT/process/index.rst +++ b/Documentation/translations/it_IT/process/index.rst @@ -58,6 +58,7 @@ perché non si è trovato un posto migliore. adding-syscalls magic-number volatile-considered-harmful + botching-up-ioctls clang-format ../riscv/patch-acceptance diff --git a/Documentation/translations/it_IT/process/kernel-docs.rst b/Documentation/translations/it_IT/process/kernel-docs.rst index 38e0a955121a..eadcbf50a1b5 100644 --- a/Documentation/translations/it_IT/process/kernel-docs.rst +++ b/Documentation/translations/it_IT/process/kernel-docs.rst @@ -6,8 +6,8 @@ .. _it_kernel_docs: -Indice di documenti per le persone interessate a capire e/o scrivere per il kernel Linux -======================================================================================== +Ulteriore Documentazione Del Kernel Linux +========================================= .. note:: Questo documento contiene riferimenti a documenti in lingua inglese; inoltre diff --git a/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst b/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst index a1e98ec9532e..5526bcabeb0a 100644 --- a/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst +++ b/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst @@ -163,7 +163,7 @@ chiave principale attraverso firme certificate. È quindi importante comprendere i seguenti punti: 1. Non ci sono differenze tecniche tra la chiave principale e la sottochiave. -2. In fesa di creazione, assegniamo limitazioni funzionali ad ogni chiave +2. In fase di creazione, assegniamo limitazioni funzionali ad ogni chiave assegnando capacità specifiche. 3. Una chiave PGP può avere 4 capacità: @@ -286,9 +286,7 @@ magari in una cassetta di sicurezza in banca. Probabilmente la vostra stampante non è più quello stupido dispositivo connesso alla porta parallela, ma dato che il suo output è comunque criptato con la passphrase, eseguire la stampa in un sistema "cloud" - moderno dovrebbe essere comunque relativamente sicuro. Un'opzione potrebbe - essere quella di cambiare la passphrase della vostra chiave primaria - subito dopo aver finito con paperkey. + moderno dovrebbe essere comunque relativamente sicuro. Copia di riserva di tutta la cartella GnuPG ------------------------------------------- diff --git a/Documentation/translations/it_IT/process/submitting-patches.rst b/Documentation/translations/it_IT/process/submitting-patches.rst index a3bb0008837a..c2cfa0948b2b 100644 --- a/Documentation/translations/it_IT/process/submitting-patches.rst +++ b/Documentation/translations/it_IT/process/submitting-patches.rst @@ -340,7 +340,7 @@ Assicuratevi di dire ai revisori quali cambiamenti state facendo e di ringraziarli per il loro tempo. Revisionare codice è un lavoro faticoso e che richiede molto tempo, e a volte i revisori diventano burberi. Tuttavia, anche in questo caso, rispondete con educazione e concentratevi sul problema che hanno -evidenziato. Quando inviate una version successiva ricordatevi di aggiungere un +evidenziato. Quando inviate una versione successiva ricordatevi di aggiungere un ``patch changelog`` alla email di intestazione o ad ogni singola patch spiegando le differenze rispetto a sottomissioni precedenti (vedere :ref:`it_the_canonical_patch_format`). diff --git a/Documentation/translations/sp_SP/process/code-of-conduct.rst b/Documentation/translations/sp_SP/process/code-of-conduct.rst new file mode 100644 index 000000000000..adc6c770cc37 --- /dev/null +++ b/Documentation/translations/sp_SP/process/code-of-conduct.rst @@ -0,0 +1,97 @@ +.. include:: ../disclaimer-sp.rst + +:Original: :ref:`Documentation/process/code-of-conduct.rst <code_of_conduct>` +:Translator: Contributor Covenant and Carlos Bilbao <carlos.bilbao@amd.com> + +.. _sp_code_of_conduct: + +Código de Conducta para Contribuyentes ++++++++++++++++++++++++++++++++++++++++ + +Nuestro Compromiso +================== + +Nosotros, como miembros, contribuyentes y administradores nos comprometemos +a hacer de la participación en nuestra comunidad una experiencia libre de +acoso para todo el mundo, independientemente de la edad, dimensión corporal, +minusvalía visible o invisible, etnicidad, características sexuales, +identidad y expresión de género, nivel de experiencia, educación, nivel +socio-económico, nacionalidad, apariencia personal, raza, religión, o +identidad u orientación sexual. Nos comprometemos a actuar e interactuar de +maneras que contribuyan a una comunidad abierta, acogedora, diversa, +inclusiva y sana. + +Nuestros Estándares +=================== + +Ejemplos de comportamiento que contribuyen a crear un ambiente positivo +para nuestra comunidad: + +* Demostrar empatía y amabilidad ante otras personas +* Respeto a diferentes opiniones, puntos de vista y experiencias +* Dar y aceptar adecuadamente retroalimentación constructiva +* Aceptar la responsabilidad y disculparse ante quienes se vean afectados + por nuestros errores, aprendiendo de la experiencia +* Centrarse en lo que sea mejor no sólo para nosotros como individuos, sino + para la comunidad en general + + +Ejemplos de comportamiento inaceptable: + +* El uso de lenguaje o imágenes sexualizadas, y aproximaciones o + atenciones sexuales de cualquier tipo +* Comentarios despectivos (trolling), insultantes o derogatorios, y ataques + personales o políticos +* El acoso en público o privado +* Publicar información privada de otras personas, tales como direcciones + físicas o de correo + electrónico, sin su permiso explícito +* Otras conductas que puedan ser razonablemente consideradas como + inapropiadas en un entorno profesional + + +Aplicación de las responsabilidades +=================================== + +Los administradores de la comunidad son responsables de aclarar y hacer +cumplir nuestros estándares de comportamiento aceptable y tomarán acciones +apropiadas y correctivas de forma justa en respuesta a cualquier +comportamiento que consideren inapropiado, amenazante, ofensivo o dañino. + +Los administradores de la comunidad tendrán el derecho y la responsabilidad +de eliminar, editar o rechazar comentarios, commits, código, ediciones de +páginas de wiki, issues y otras contribuciones que no se alineen con este +Código de Conducta, y comunicarán las razones para sus decisiones de +moderación cuando sea apropiado. + +Alcance +======= + +Este código de conducta aplica tanto a espacios del proyecto como a +espacios públicos donde un individuo esté en representación del proyecto o +comunidad. Ejemplos de esto incluyen el uso de la cuenta oficial de correo +electrónico, publicaciones a través de las redes sociales oficiales, o +presentaciones con personas designadas en eventos en línea o no. + +Aplicación +========== + +Instancias de comportamiento abusivo, acosador o inaceptable de otro modo +podrán ser reportadas contactando el Code of Conduct Commitee a través de +<conduct@kernel.org>. Todas las quejas serán evaluadas e investigadas de +una manera puntual y justa. El Code of Condut Commitee está obligados a +respetar la privacidad y la seguridad de quienes reporten incidentes. +Detalles de políticas y aplicación en particular, serán incluidos por +separado. + +Atribución +========== + +Este Código de Conducta es una adaptación del Contributor Covenant, versión +1.4, disponible en https://www.contributor-covenant.org/version/1/4/code-of-conduct.html + +Interpretación +============== + +Consulte el documento :ref:`code_of_conduct_interpretation` para ver cómo +interpretará la comunidad del kernel Linux este documento. diff --git a/Documentation/translations/sp_SP/process/email-clients.rst b/Documentation/translations/sp_SP/process/email-clients.rst new file mode 100644 index 000000000000..fdf1e51b84e4 --- /dev/null +++ b/Documentation/translations/sp_SP/process/email-clients.rst @@ -0,0 +1,374 @@ +.. include:: ../disclaimer-sp.rst + +:Original: :ref:`Documentation/process/email-clients.rst <email_clients>` +:Translator: Carlos Bilbao <carlos.bilbao@amd.com> + +.. _sp_email_clients: + +Información de clientes de correo electrónico para Linux +======================================================== + +Git +--- + +A día de hoy, la mayoría de los desarrolladores usan ``git send-email`` en +lugar de los clientes de correo electrónico normales. La página de manual +para esto es bastante buena. En la recepción del correo, los maintainers +usan ``git am`` para aplicar los parches. + +Si es usted nuevo en ``git`` entonces envíese su primer parche. Guárdelo +como texto sin formato, incluidos todos los encabezados. Ejecute ``git am raw_email.txt`` +y luego revise el registro de cambios con ``git log``. Cuando eso funcione, +envíe el parche a la(s) lista(s) de correo apropiada(s). + +Preferencias Generales +---------------------- + +Los parches para el kernel de Linux se envían por correo electrónico, +preferiblemente como texto en línea en el cuerpo del correo electrónico. +Algunos maintainers aceptan archivos adjuntos, pero entonces los archivos +adjuntos deben tener tipo de contenido ``text/plain``. Sin embargo, los +archivos adjuntos generalmente están mal vistos porque hacen que citar +partes del parche sea más difícil durante el proceso de revisión del +parche. + +También se recomienda encarecidamente que utilice texto sin formato en el +cuerpo del correo electrónico, para parches y otros correos electrónicos +por igual. https://useplaintext.email puede ser útil para obtener +información sobre cómo configurar su cliente de correo electrónico +preferido, así como una lista de clientes de correo electrónico +recomendados si aún no tiene una preferencia. + +Los clientes de correo electrónico que se utilizan para los parches del +kernel Linux deben enviar el texto del parche intacto. Por ejemplo, no +deben modificar ni eliminar pestañas o espacios, incluso al principio o al +final de las líneas. + +No envíe parches con ``format=flowed``. Esto puede causar saltos de línea +no deseados e inesperados. + +No deje que su cliente de correo electrónico ajuste automáticamente las +palabras por usted. Esto también puede corromper su parche. + +Los clientes de correo electrónico no deben modificar la codificación del +de caracteres del texto. Los parches enviados por correo electrónico deben +estar en codificación ASCII o UTF-8 únicamente. Si configura su cliente de +correo electrónico para enviar correos electrónicos con codificación UTF-8, +evite algunos posibles problemas con los caracteres. + +Los clientes de correo electrónico deben generar y mantener los +encabezados "References:" o "In-Reply-To:" para que el hilo de correo no +se rompa. + +Copiar y pegar (o cortar y pegar) generalmente no funciona para los +parches, porque las tabulaciones se convierten en espacios. Utilizar +xclipboard, xclip y/o xcutsel puede funcionar, pero es mejor probarlo usted +mismo o simplemente evitar copiar y pegar. + +No utilice firmas PGP/GPG en el correo que contiene parches. +Esto rompe muchos scripts que leen y aplican los parches. +(Esto debería ser reparable.) + +Es una buena idea enviarse un parche a sí mismo, guardar el mensaje +recibido, y aplicarlo con éxito con 'patch' antes de enviar el parche a las +listas de correo de Linux. + +Algunas sugerencias para el cliente de correo electrónico (MUA) +--------------------------------------------------------------- + +Aquí hay algunos consejos específicos de configuración de MUA para editar y +enviar parches para el kernel de Linux. Estos no pretenden cubrir todo +detalle de configuración de los paquetes de software. + +Leyenda: + +- TUI = text-based user interface (interfaz de usuario basada en texto) +- GUI = graphical user interface (interfaz de usuario gráfica) + +Alpine (TUI) +************ + +Opciones de configuración: + +En la sección :menuselection:`Sending Preferences`: + +- :menuselection: `Do Not Send Flowed Text` debe estar ``enabled`` +- :menuselection:`Strip Whitespace Before Sending` debe estar ``disabled`` + +Al redactar el mensaje, el cursor debe colocarse donde el parche debería +aparecer, y luego presionando :kbd:`CTRL-R` se le permite especificar e +archivo de parche a insertar en el mensaje. + +Claws Mail (GUI) +**************** + +Funciona. Algunos usan esto con éxito para los parches. + +Para insertar un parche haga :menuselection:`Message-->Insert File` (:kbd:`CTRL-I`) +o use un editor externo. + +Si el parche insertado debe editarse en la ventana de composición de Claws +"Auto wrapping" en +:menuselection:`Configuration-->Preferences-->Compose-->Wrapping` debe +permanecer deshabilitado. + +Evolution (GUI) +*************** + +Algunos usan esto con éxito para sus parches. + +Cuando escriba un correo seleccione: Preformat + desde :menuselection:`Format-->Paragraph Style-->Preformatted` (:kbd:`CTRL-7`) + o en la barra de herramientas + +Luego haga: +:menuselection:`Insert-->Text File...` (:kbd:`ALT-N x`) +para insertar el parche. + +También puede hacer ``diff -Nru old.c new.c | xclip``, seleccione +:menuselection:`Preformat`, luego pege con el boton del medio. + +Kmail (GUI) +*********** + +Algunos usan Kmail con éxito para los parches. + +La configuración predeterminada de no redactar en HTML es adecuada; no haga +cambios en esto. + +Al redactar un correo electrónico, en las opciones, desmarque "word wrap". +La única desventaja es que cualquier texto que escriba en el correo +electrónico no se ajustará a cada palabra, por lo que tendrá que ajustar +manualmente el texto antes del parche. La forma más fácil de evitar esto es +redactar su correo electrónico con Word Wrap habilitado, luego guardar +como borrador. Una vez que lo vuelva a sacar de sus borradores, estará +envuelto por palabras y puede desmarcar "word wrap" sin perder el existente +texto. + +En la parte inferior de su correo electrónico, coloque el delimitador de +parche de uso común antes de insertar su parche: tres guiones (``---``). + +Luego desde la opción de menu :menuselection:`Message` seleccione +:menuselection:`insert file` y busque su parche. +De forma adicional, puede personalizar el menú de la barra de herramientas +de creación de mensajes y poner el icono :menuselection:`insert file`. + +Haga que la ventana del editor sea lo suficientemente ancha para que no se +envuelva ninguna línea. A partir de KMail 1.13.5 (KDE 4.5.4), KMail +aplicará ajuste de texto al enviar el correo electrónico si las líneas se +ajustan en la ventana del redactor. Tener ajuste de palabras deshabilitado +en el menú Opciones no es suficiente. Por lo tanto, si su parche tiene +líneas muy largas, debe hacer que la ventana del redactor sea muy amplia +antes de enviar el correo electrónico. Consulte: https://bugs.kde.org/show_bug.cgi?id=174034 + +You can safely GPG sign attachments, but inlined text is preferred for +patches so do not GPG sign them. Signing patches that have been inserted +as inlined text will make them tricky to extract from their 7-bit encoding. + +Puede firmar archivos adjuntos con GPG de forma segura, pero se prefiere el +texto en línea para parches, así que no los firme con GPG. Firmar parches +que se han insertado como texto en línea hará que sea difícil extraerlos de +su codificación de 7 bits. + +Si es absolutamente necesario enviar parches como archivos adjuntos en +lugar de como texto en línea, haga clic con el botón derecho en el archivo +adjunto y seleccione :menuselection:`properties`, y luego +:menuselection:`Suggest automatic display` para hacer que el archivo +adjunto esté en línea para que sea más visible. + +Al guardar parches que se envían como texto en línea, seleccione el correo +electrónico que contiene el parche del panel de la lista de mensajes, haga +clic con el botón derecho y seleccione :menuselection:`save as`. Puede usar +todo el correo electrónico sin modificar como un parche de estar bien +compuesto. Los correos electrónicos se guardan como lectura y escritura +solo para el usuario, por lo que tendrá que cambiarlos para que sean +legibles en grupo y en todo el mundo si copia estos en otro lugar. + +Notas de Lotus (GUI) +******************** + +Huya de este. + +IBM Verse (Web GUI) +******************* + +Vea notas sobre Lotus. + +Mutt (TUI) +********** + +Muchos desarrolladores de Linux usan ``mutt``, por lo que debe funcionar +bastante bien. + +Mutt no viene con un editor, por lo que cualquier editor que use debe ser +utilizado de forma que no haya saltos de línea automáticos. La mayoría de +los editores tienen una opción :menuselection:`insert file` que inserta el +contenido de un archivo inalterado. + +Para usar ``vim`` con mutt:: + + set editor="vi" + +Si utiliza xclip, escriba el comando:: + + :set paste + +antes del boton del medio o shift-insert o use:: + + :r filename + +si desea incluir el parche en línea. +(a)ttach (adjuntar) funciona bien sin ``set paste``. + +También puedes generar parches con ``git format-patch`` y luego usar Mutt +para enviarlos:: + + $ mutt -H 0001-some-bug-fix.patch + +Opciones de configuración: + +Debería funcionar con la configuración predeterminada. +Sin embargo, es una buena idea establecer ``send_charset`` en: + + set send_charset="us-ascii:utf-8" + +Mutt es altamente personalizable. Aquí tiene una configuración mínima para +empezar a usar Mutt para enviar parches a través de Gmail:: + + # .muttrc + # ================ IMAP ==================== + set imap_user = 'suusuario@gmail.com' + set imap_pass = 'sucontraseña' + set spoolfile = imaps://imap.gmail.com/INBOX + set folder = imaps://imap.gmail.com/ + set record="imaps://imap.gmail.com/[Gmail]/Sent Mail" + set postponed="imaps://imap.gmail.com/[Gmail]/Drafts" + set mbox="imaps://imap.gmail.com/[Gmail]/All Mail" + + # ================ SMTP ==================== + set smtp_url = "smtp://username@smtp.gmail.com:587/" + set smtp_pass = $imap_pass + set ssl_force_tls = yes # Requerir conexión encriptada + + # ================ Composición ==================== + set editor = `echo \$EDITOR` + set edit_headers = yes # Ver los encabezados al editar + set charset = UTF-8 # valor de $LANG; also fallback for send_charset + # El remitente, la dirección de correo electrónico y la línea de firma deben coincidir + unset use_domain # Porque joe@localhost es simplemente vergonzoso + set realname = "SU NOMBRE" + set from = "username@gmail.com" + set use_from = yes + +Los documentos Mutt tienen mucha más información: + + https://gitlab.com/muttmua/mutt/-/wikis/UseCases/Gmail + + http://www.mutt.org/doc/manual/ + +Pine (TUI) +********** + +Pine ha tenido algunos problemas de truncamiento de espacios en blanco en +el pasado, pero estos todo debería estar arreglados ahora. + +Use alpine (sucesor de pino) si puede. + +Opciones de configuración: + +- ``quell-flowed-text`` necesitado para versiones actuales +- la opción ``no-strip-whitespace-before-send`` es necesaria + + +Sylpheed (GUI) +************** + +- Funciona bien para insertar texto (o usar archivos adjuntos). +- Permite el uso de un editor externo. +- Es lento en carpetas grandes. +- No realizará la autenticación TLS SMTP en una conexión que no sea SSL. +- Tiene una útil barra de reglas en la ventana de redacción. +- Agregar direcciones a la libreta de direcciones no las muestra + adecuadamente. + +Thunderbird (GUI) +***************** + +Thunderbird es un clon de Outlook al que le gusta alterar el texto, pero +hay formas para obligarlo a comportarse. + +Después de hacer las modificaciones, que incluye instalar las extensiones, +necesita reiniciar Thunderbird. + +- Permitir el uso de un editor externo: + + Lo más fácil de hacer con Thunderbird y los parches es usar extensiones + que abran su editor externo favorito. + + Aquí hay algunas extensiones de ejemplo que son capaces de hacer esto. + + - "External Editor Revived" + + https://github.com/Frederick888/external-editor-revived + + https://addons.thunderbird.net/en-GB/thunderbird/addon/external-editor-revived/ + + Requiere instalar un "native messaging host". + Por favor, lea la wiki que se puede encontrar aquí: + https://github.com/Frederick888/external-editor-revived/wiki + + - "External Editor" + + https://github.com/exteditor/exteditor + + Para hacer esto, descargue e instale la extensión, luego abra la ventana + :menuselection:`compose`, agregue un botón para ello usando + :menuselection:`View-->Toolbars-->Customize...` + luego simplemente haga clic en el botón nuevo cuando desee usar el editor + externo. + + Tenga en cuenta que "External Editor" requiere que su editor no haga + fork, o en otras palabras, el editor no debe regresar antes de cerrar. + Es posible que deba pasar flags adicionales o cambiar la configuración + de su editor. En particular, si está utilizando gvim, debe pasar la + opción -f a gvim poniendo ``/usr/bin/gvim --nofork"`` (si el binario + está en ``/usr/bin``) al campo del editor de texto en los ajustes + :menuselection:`external editor`. Si está utilizando algún otro editor, + lea su manual para saber cómo hacer esto. + +Para sacarle algo de sentido al editor interno, haga esto: + +- Edite sus ajustes de configuración de Thunderbird para que no utilice ``format=flowed``! + Vaya a su ventana principal y busque el botón de su menú desplegable principal. + :menuselection:`Main Menu-->Preferences-->General-->Config Editor...` + para abrir el editor de registro de Thunderbird. + + - Seleccione ``mailnews.send_plaintext_flowed`` como ``false`` + + - Seleccione ``mailnews.wraplength`` de ``72`` a ``0`` + +- ¡No escriba mensajes HTML! Acuda a la ventana principal + :menuselection:`Main Menu-->Account Settings-->youracc@server.something-->Composition & Addressing`! + Ahí puede deshabilitar la opción "Compose messages in HTML format". + +- ¡Abra mensajes solo como texto sin formato! Acuda a la ventana principal + :menuselection:`Main Menu-->View-->Message Body As-->Plain Text`! + +TkRat (GUI) +*********** + +Funciona. Utilice "Insert file..." o un editor externo. + +Gmail (Web GUI) +*************** + +No funciona para enviar parches. + +El cliente web de Gmail convierte las tabulaciones en espacios automáticamente. + +Al mismo tiempo, envuelve líneas cada 78 caracteres con saltos de línea de +estilo CRLF aunque el problema de tab2space se puede resolver con un editor +externo. + +Otro problema es que Gmail codificará en base64 cualquier mensaje que tenga +un carácter no ASCII. Eso incluye cosas como nombres europeos. diff --git a/Documentation/translations/sp_SP/process/index.rst b/Documentation/translations/sp_SP/process/index.rst index 49a05f6a5544..c978a8132ce1 100644 --- a/Documentation/translations/sp_SP/process/index.rst +++ b/Documentation/translations/sp_SP/process/index.rst @@ -13,3 +13,7 @@ submitting-patches kernel-docs coding-style + code-of-conduct + kernel-enforcement-statement + email-clients + magic-number diff --git a/Documentation/translations/sp_SP/process/kernel-enforcement-statement.rst b/Documentation/translations/sp_SP/process/kernel-enforcement-statement.rst new file mode 100644 index 000000000000..d66902694089 --- /dev/null +++ b/Documentation/translations/sp_SP/process/kernel-enforcement-statement.rst @@ -0,0 +1,174 @@ +.. include:: ../disclaimer-sp.rst + +:Original: :ref:`Documentation/process/kernel-enforcement-statement.rst <process_statement_kernel>` +:Translator: Carlos Bilbao <carlos.bilbao@amd.com> + +.. _sp_process_statement_kernel: + +Aplicación de la licencia en el kernel Linux +============================================ + +Como desarrolladores del kernel Linux, tenemos un gran interés en cómo se +se utiliza nuestro software y cómo se aplica la licencia de nuestro software. +El cumplimiento de las obligaciones de intercambio recíproco de GPL-2.0 son +fundamentales en el largo plazo para la sostenibilidad de nuestro software +y comunidad. + +Aunque existe el derecho de hacer valer un copyright distinto en las +contribuciones hechas a nuestra comunidad, compartimos el interés de +asegurar que las acciones individuales para proteger estos se lleven a cabo +de una manera que beneficia a nuestra comunidad y no tenga un indeseado +impacto negativo en la salud y crecimiento de nuestro ecosistema de software. +Con el fin de disuadir la aplicación inútil de acciones, estamos de acuerdo +en que es en el mejor interés de nuestro desarrollo como comunidad asumir +el siguiente compromiso con los usuarios del kernel Linux, en nombre +nuestro y de cualquier sucesor de nuestros derechos de autor (copyright): + + Sin perjuicio de las disposiciones de terminación de GPL-2.0, aceptamos + que es en el mejor interés de nuestra comunidad de desarrollo adoptar + las siguientes disposiciones de GPL-3.0 como permisos adicionales bajo + nuestra licencia, con respecto a cualquier interposición de alegación + de infringimiento (en inglés, "non-defensive assertion") de los + derechos bajo la licencia. + + Sin embargo, si deja de violar esta Licencia, entonces su licencia + de copyright como particular se restablece (a) provisionalmente, + a menos que y hasta que el titular de los derechos de autor explícita + y finalmente rescinda su licencia, y (b) de forma permanente, si el + titular de los derechos de autor no le notifica la violación por algún + medio razonable antes de 60 días después del cese. + + Además, su licencia de un titular de derechos de autor en particular es + restablecida permanentemente si el titular de los derechos de autor le + notifica de la violación por algún medio razonable, esta es la primera + vez que ha recibido notificación de violación de esta Licencia (para + cualquier trabajo) de ese titular de los derechos de autor, y subsana + la infracción antes de los 30 días posteriores de recibir el aviso. + +Nuestra intención al proporcionar estas garantías es fomentar un mayor uso +del software. Queremos que empresas y particulares utilicen, modifiquen y +distribuyan este software. Queremos trabajar con los usuarios de forma +abierta y transparente para eliminar cualquier incertidumbre sobre nuestras +expectativas con respecto al cumplimiento que podría limitar la adopción de +nuestro software. Entendemos la acción legal como último recurso, que se +iniciará solo cuando otros esfuerzos de la comunidad no hayan podido +resolver el problema. + +Finalmente, una vez que se resuelva un problema de incumplimiento, +esperamos que el usuario se sienta bienvenido a unirse a nosotros en +nuestros esfuerzos con este proyecto. Trabajando juntos, somos más fuertes. + +Excepto donde se indica a continuación, hablamos solo por nosotros mismos y +no por ninguna compañía donde puede que trabajemos hoy, o hayamos trabajado +en el pasado, o trabajaremos en el futuro. + +- Laura Abbott +- Bjorn Andersson (Linaro) +- Andrea Arcangeli +- Neil Armstrong +- Jens Axboe +- Pablo Neira Ayuso +- Khalid Aziz +- Ralf Baechle +- Felipe Balbi +- Arnd Bergmann +- Ard Biesheuvel +- Tim Bird +- Paolo Bonzini +- Christian Borntraeger +- Mark Brown (Linaro) +- Paul Burton +- Javier Martinez Canillas +- Rob Clark +- Kees Cook (Google) +- Jonathan Corbet +- Dennis Dalessandro +- Vivien Didelot (Savoir-faire Linux) +- Hans de Goede +- Mel Gorman (SUSE) +- Sven Eckelmann +- Alex Elder (Linaro) +- Fabio Estevam +- Larry Finger +- Bhumika Goyal +- Andy Gross +- Juergen Gross +- Shawn Guo +- Ulf Hansson +- Stephen Hemminger (Microsoft) +- Tejun Heo +- Rob Herring +- Masami Hiramatsu +- Michal Hocko +- Simon Horman +- Johan Hovold (Hovold Consulting AB) +- Christophe JAILLET +- Olof Johansson +- Lee Jones (Linaro) +- Heiner Kallweit +- Srinivas Kandagatla +- Jan Kara +- Shuah Khan (Samsung) +- David Kershner +- Jaegeuk Kim +- Namhyung Kim +- Colin Ian King +- Jeff Kirsher +- Greg Kroah-Hartman (Linux Foundation) +- Christian König +- Vinod Koul +- Krzysztof Kozlowski +- Viresh Kumar +- Aneesh Kumar K.V +- Julia Lawall +- Doug Ledford +- Chuck Lever (Oracle) +- Daniel Lezcano +- Shaohua Li +- Xin Long +- Tony Luck +- Catalin Marinas (Arm Ltd) +- Mike Marshall +- Chris Mason +- Paul E. McKenney +- Arnaldo Carvalho de Melo +- David S. Miller +- Ingo Molnar +- Kuninori Morimoto +- Trond Myklebust +- Martin K. Petersen (Oracle) +- Borislav Petkov +- Jiri Pirko +- Josh Poimboeuf +- Sebastian Reichel (Collabora) +- Guenter Roeck +- Joerg Roedel +- Leon Romanovsky +- Steven Rostedt (VMware) +- Frank Rowand +- Ivan Safonov +- Anna Schumaker +- Jes Sorensen +- K.Y. Srinivasan +- David Sterba (SUSE) +- Heiko Stuebner +- Jiri Kosina (SUSE) +- Willy Tarreau +- Dmitry Torokhov +- Linus Torvalds +- Thierry Reding +- Rik van Riel +- Luis R. Rodriguez +- Geert Uytterhoeven (Glider bvba) +- Eduardo Valentin (Amazon.com) +- Daniel Vetter +- Linus Walleij +- Richard Weinberger +- Dan Williams +- Rafael J. Wysocki +- Arvind Yadav +- Masahiro Yamada +- Wei Yongjun +- Lv Zheng +- Marc Zyngier (Arm Ltd) + diff --git a/Documentation/translations/sp_SP/process/magic-number.rst b/Documentation/translations/sp_SP/process/magic-number.rst new file mode 100644 index 000000000000..2b62cec34e8e --- /dev/null +++ b/Documentation/translations/sp_SP/process/magic-number.rst @@ -0,0 +1,90 @@ +.. include:: ../disclaimer-sp.rst + +:Original: :ref:`Documentation/process/magic-number.rst <magicnumbers>` +:Translator: Carlos Bilbao <carlos.bilbao@amd.com> + +.. _sp_magicnumbers: + +Números mágicos de Linux +======================== + +Este archivo es un registro de los números mágicos que están en uso. Cuando +usted incluya un número mágico a una estructura, también debe agregarlo a +este documento, ya que es mejor si los números mágicos utilizados por +varias estructuras son únicos. + +Es una muy buena idea proteger las estructuras de datos del kernel con +números mágicos. Esto le permite verificar en tiempo de ejecución si (a) +una estructura ha sido manipulada, o (b) ha pasado la estructura incorrecta +a una rutina. Esto último es especialmente útil --- particularmente cuando +pasa punteros a estructuras a través de un puntero void \*. El código tty, +por ejemplo, hace esto con frecuencia para pasar información específica del +driver y líneas de estructuras específicas de protocolo de un lado al +otro. + +La forma de usar números mágicos es declararlos al principio de la +estructura, así:: + + struct tty_ldisc { + int magic; + ... + }; + +Por favor, siga este método cuando agregue futuras mejoras al kernel! Me ha +ahorrado innumerables horas de depuración, especialmente en los casos +complicados donde una matriz ha sido invadida y las estructuras que siguen +a la matriz se han sobrescrito. Usando este método, estos casos se detectan +de forma rápida y segura. + +Changelog:: + + Theodore Ts'o + 31 Mar 94 + + La tabla mágica ha sido actualizada para Linux 2.1.55. + + Michael Chastain + <mailto:mec@shout.net> + 22 Sep 1997 + + Ahora debería estar actualizada con Linux 2.1.112. Porque + estamos en fase de "feature freeze", es muy poco probable que + algo cambiará antes de 2.2.x. Las entradas son + ordenados por campo numérico. + + Krzysztof G. Baranowski + <mailto: kgb@knm.org.pl> + 29 Jul 1998 + + Se actualizó la tabla mágica a Linux 2.5.45. Justo sobre el feature + freeze, pero es posible que algunos nuevos números mágicos se cuelen en + el kernel antes de 2.6.x todavía. + + Petr Baudis + <pasky@ucw.cz> + 03 Nov 2002 + + La tabla mágica ha sido actualizada para Linux 2.5.74. + + Fabian Frederick + <ffrederick@users.sourceforge.net> + 09 Jul 2003 + +===================== ================ ======================== ========================================== +Magic Name Number Structure File +===================== ================ ======================== ========================================== +PG_MAGIC 'P' pg_{read,write}_hdr ``include/linux/pg.h`` +APM_BIOS_MAGIC 0x4101 apm_user ``arch/x86/kernel/apm_32.c`` +FASYNC_MAGIC 0x4601 fasync_struct ``include/linux/fs.h`` +SLIP_MAGIC 0x5302 slip ``drivers/net/slip.h`` +MGSLPC_MAGIC 0x5402 mgslpc_info ``drivers/char/pcmcia/synclink_cs.c`` +BAYCOM_MAGIC 0x19730510 baycom_state ``drivers/net/baycom_epp.c`` +HDLCDRV_MAGIC 0x5ac6e778 hdlcdrv_state ``include/linux/hdlcdrv.h`` +KV_MAGIC 0x5f4b565f kernel_vars_s ``arch/mips/include/asm/sn/klkernvars.h`` +CODA_MAGIC 0xC0DAC0DA coda_file_info ``fs/coda/coda_fs_i.h`` +YAM_MAGIC 0xF10A7654 yam_port ``drivers/net/hamradio/yam.c`` +CCB_MAGIC 0xf2691ad2 ccb ``drivers/scsi/ncr53c8xx.c`` +QUEUE_MAGIC_FREE 0xf7e1c9a3 queue_entry ``drivers/scsi/arm/queue.c`` +QUEUE_MAGIC_USED 0xf7e1cc33 queue_entry ``drivers/scsi/arm/queue.c`` +NMI_MAGIC 0x48414d4d455201 nmi_s ``arch/mips/include/asm/sn/nmi.h`` +===================== ================ ======================== ========================================== diff --git a/Documentation/translations/zh_CN/PCI/msi-howto.rst b/Documentation/translations/zh_CN/PCI/msi-howto.rst index 7ea4d50cdad2..1b9b5ea790d8 100644 --- a/Documentation/translations/zh_CN/PCI/msi-howto.rst +++ b/Documentation/translations/zh_CN/PCI/msi-howto.rst @@ -231,3 +231,14 @@ ACPI FADT表中指明了它。在这种情况下，Linux会自动禁用MSI。有 也需要检查设备驱动程序，看它是否支持MSI。例如，它可能包含对带有PCI_IRQ_MSI或 PCI_IRQ_MSIX标志的pci_alloc_irq_vectors（）的调用。 + + +MSI(-X) APIs设备驱动程序列表 +============================ + +PCI/MSI子系统有一个专门的C文件，用于其导出的设备驱动程序APIs - `drivers/pci/msi/api.c` 。 +以下是导出的函数: + +该API在以下内核代码中: + +drivers/pci/msi/api.c diff --git a/Documentation/translations/zh_CN/accounting/delay-accounting.rst b/Documentation/translations/zh_CN/accounting/delay-accounting.rst index f1849411018e..a01dc3d5b0db 100644 --- a/Documentation/translations/zh_CN/accounting/delay-accounting.rst +++ b/Documentation/translations/zh_CN/accounting/delay-accounting.rst @@ -17,8 +17,9 @@ a) 等待一个CPU（任务为可运行） b) 完成由该任务发起的块I/O同步请求 c) 页面交换 d) 内存回收 -e) 页缓存抖动 +e) 抖动 f) 直接规整 +g) 写保护复制 并将这些统计信息通过taskstats接口提供给用户空间。 @@ -42,7 +43,7 @@ f) 直接规整 include/uapi/linux/taskstats.h 其描述了延时计数相关字段。系统通常以计数器形式返回 CPU、同步块 I/O、交换、内存 -回收、页缓存抖动、直接规整等的累积延时。 +回收、页缓存抖动、直接规整、写保护复制等的累积延时。 取任务某计数器两个连续读数的差值，将得到任务在该时间间隔内等待对应资源的总延时。 @@ -100,6 +101,8 @@ getdelays命令的一般格式:: 0 0 0ms COMPACT count delay total delay average 0 0 0ms + WPCOPY count delay total delay average + 0 0 0ms 获取pid为1的IO计数，它只和-p一起使用:: # ./getdelays -i -p 1 diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst index 30c69e1f44fe..6f8676a50b38 100644 --- a/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst @@ -22,6 +22,7 @@ start usage reclaim + lru_sort diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/lru_sort.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/lru_sort.rst new file mode 100644 index 000000000000..812ef315c8f6 --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/lru_sort.rst @@ -0,0 +1,263 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../../disclaimer-zh_CN.rst + +:Original: Documentation/admin-guide/mm/damon/lru_sort.rst + +:翻译: + + 臧雷刚 Leigang Zang <zangleigang@hisilicon.com> + +:校译: + +================== +基于DAMON的LRU排序 +================== + +基于DAMON的LRU排序是一个静态的内核模块，旨在用于以主动的、轻量级的数据访问模型 +为基础的页面优先级处理的LRU链表上，以使得LRU上的数据访问模型更为可信。 + +哪里需要主动的LRU排序 +===================== + +在一个大型系统中，以页为粒度的访问检测会有比较显著的开销，LRU通常不会主动去排序， +而是对部分特殊事件进行部分的、响应式的排序，例如：特殊的用户请求，系统调用或者 +内存压力。这导致，在有些场景下，LRU不能够完美的作为一个可信的数据访问模型，比如 +在内存压力下对目标内存进行回收。 + +因为DAMON能够尽可能准确的识别数据访问模型，同时只引起用户指定范围的开销，主动的 +执行DAMON_LRU_SORT让LRU变得更为可信是有益的，而且这只需要较少和可控的开销。 + +这是如何工作的 +============== + +DAMON_LRU_SORT使用DAMON寻找热页（范围内的页面访问频率高于用户指定的阈值）和冷页 +（范围内的页面在超过用户指定的时间无访问），并提高热页和降低冷页在LRU中的优先级。 +为了避免在排序过程占用更多的CPU计算资源，可以设置一个CPU占用时间的约束值。在约 +束下，分别提升或者降低更多的热页和冷页。系统管理员也可以配置三个内存水位以控制 +在何种条件下自动激活或者停止这种机制。 + +冷热阈值和CPU约束的默认值是比较保守的。这意味着，在默认参数下，模块可以广泛且无 +负作用的使用在常见环境中，同时在只消耗一小部分CPU时间的情况下，给有内存压力的系 +统提供一定水平的冷热识别。 + +接口：模块参数 +============== + +使用此特性，你首先需要确认你的系统中运行的内核在编译时启用了 +``CONFIG_DAMON_LRU_SORT=y``. + +为了让系统管理员打开或者关闭并且调节指定的系统，DAMON_LRU_SORT设计了模块参数。 +这意味着，你可以添加 ``damon_lru_sort.<parameter>=<value>`` 到内核的启动命令行 +参数，或者在 ``/sys/modules/damon_lru_sort/parameters/<parameter>`` 写入正确的 +值。 + +下边是每个参数的描述 + +enabled +------- + +打开或者关闭DAMON_LRU_SORT. + +你可以通过设置这个参数为 ``Y`` 来打开DAMON_LRU_SORT。设置为 ``N`` 关闭 +DAMON_LRU_SORT。注意，在基于水位的激活的情况下，DAMON_LRU_SORT有可能不会真正去 +监测或者做LRU排序。对这种情况，参考下方关于水位的描述。 + +commit_inputs +------------- + +让DAMON_LRU_SORT再次读取输入参数，除了 ``enabled`` 。 + +在DAMON_LRU_SORT运行时，新的输入参数默认不会被应用。一旦这个参数被设置为 ``Y`` +，DAMON_LRU_SORT会再次读取除了 ``enabled`` 之外的参数。读取完成后，这个参数会被 +设置为 ``N`` 。如果在读取时发现有无效参数，DAMON_LRU_SORT会被关闭。 + +hot_thres_access_freq +--------------------- + +热点内存区域的访问频率阈值，千分比。 + +如果一个内存区域的访问频率大于等于这个值，DAMON_LRU_SORT把这个区域看作热区，并 +在LRU上把这个区域标记为已访问，因些在内存压力下这部分内存不会被回收。默认为50%。 + +cold_min_age +------------ + +用于识别冷内存区域的时间阈值，单位是微秒。 + +如果一个内存区域在这个时间内未被访问过，DAMON_LRU_SORT把这个区域看作冷区，并在 +LRU上把这个区域标记为未访问，因此在内存压力下这些内存会首先被回收。默认值为120 +秒。 + +quota_ms +-------- + +尝试LRU链表排序的时间限制，单位是毫秒。 + +DAMON_LRU_SORT在一个时间窗口内（quota_reset_interval_ms）内最多尝试这么长时间来 +对LRU进行排序。这个可以用来作为CPU计算资源的约束。如果值为0，则表示无限制。 + +默认10毫秒。 + +quota_reset_interval_ms +----------------------- + +配额计时重置周期，毫秒。 + +配额计时重置周期。即，在quota_reset_interval_ms毫秒内，DAMON_LRU_SORT对LRU进行 +排序不会超过quota_ms或者quota_sz。 + +默认1秒。 + +wmarks_interval +--------------- + +水位的检查周期，单位是微秒。 + +当DAMON_LRU_SORT使能但是由于水位而不活跃时检查水位前最小的等待时间。默认值5秒。 + +wmarks_high +----------- + +空闲内存高水位，千分比。 + +如果空闲内存水位高于这个值，DAMON_LRU_SORT停止工作，不做任何事，除了周期性的检 +查水位。默认200(20%)。 + +wmarks_mid +---------- + +空闲内存中间水位，千分比。 + +如果空闲内存水位在这个值与低水位之间，DAMON_LRU_SORT开始工作，开始检测并对LRU链 +表进行排序。默认150(15%)。 + +wmarks_low +---------- + +空闲内存低水位，千分比。 + +如果空闲内存小于这个值，DAMON_LRU_SORT不再工作，不做任何事，除了周期性的检查水 +线。默认50(5%)。 + +sample_interval +--------------- + +监测的采样周期，微秒。 + +DAMON对冷内存监测的采样周期。更多细节请参考DAMON文档 (:doc:`usage`) 。默认5 +毫秒。 + +aggr_interval +------------- + +监测的收集周期，微秒。 + +DAMON对冷内存进行收集的时间周期。更多细节请参考DAMON文档 (:doc:`usage`) 。默认 +100毫秒。 + +min_nr_regions +-------------- + +最小监测区域数量。 + +对冷内存区域监测的最小数量。这个值可以作为监测质量的下限。不过，这个值设置的过 +大会增加开销。更多细节请参考DAMON文档 (:doc:`usage`) 。默认值为10。 + +max_nr_regions +-------------- + +最大监测区域数量。 + +对冷内存区域监测的最大数量。这个值可以作为监测质量的上限。然而，这个值设置的过 +低会导致监测结果变差。更多细节请参考DAMON文档 (:doc:`usage`) 。默认值为1000。 + +monitor_region_start +-------------------- + +目标内存区域的起始物理地址。 + +DAMON_LRU_SORT要处理的目标内存区域的起始物理地址。默认，使用系统最大内存。 + +monitor_region_end +------------------ + +目标内存区域的结束物理地址。 + +DAMON_LRU_SORT要处理的目标内存区域的结束物理地址。默认，使用系统最大内存。 + +kdamond_pid +----------- + +DAMON线程的PID。 + +如果DAMON_LRU_SORT是使能的，这个表示任务线程的PID。其它情况为-1。 + +nr_lru_sort_tried_hot_regions +----------------------------- + +被尝试进行LRU排序的热内存区域的数量。 + +bytes_lru_sort_tried_hot_regions +-------------------------------- + +被尝试进行LRU排序的热内存区域的大小（字节）。 + +nr_lru_sorted_hot_regions +------------------------- + +成功进行LRU排序的热内存区域的数量。 + +bytes_lru_sorted_hot_regions +---------------------------- + +成功进行LRU排序的热内存区域的大小（字节）。 + +nr_hot_quota_exceeds +-------------------- + +热区域时间约束超过限制的次数。 + +nr_lru_sort_tried_cold_regions +------------------------------ + +被尝试进行LRU排序的冷内存区域的数量。 + +bytes_lru_sort_tried_cold_regions +--------------------------------- + +被尝试进行LRU排序的冷内存区域的大小（字节）。 + +nr_lru_sorted_cold_regions +-------------------------- + +成功进行LRU排序的冷内存区域的数量。 + +bytes_lru_sorted_cold_regions +----------------------------- + +成功进行LRU排序的冷内存区域的大小（字节）。 + +nr_cold_quota_exceeds +--------------------- + +冷区域时间约束超过限制的次数。 + +Example +======= + +如下是一个运行时的命令示例，使DAMON_LRU_SORT查找访问频率超过50%的区域并对其进行 +LRU的优先级的提升，同时降低那些超过120秒无人访问的内存区域的优先级。优先级的处 +理被限制在最多1%的CPU以避免DAMON_LRU_SORT消费过多CPU时间。在系统空闲内存超过50% +时DAMON_LRU_SORT停止工作，并在低于40%时重新开始工作。如果DAMON_RECLAIM没有取得 +进展且空闲内存低于20%，再次让DAMON_LRU_SORT停止工作，以此回退到以LRU链表为基础 +以页面为单位的内存回收上。 + + # cd /sys/modules/damon_lru_sort/parameters + # echo 500 > hot_thres_access_freq + # echo 120000000 > cold_min_age + # echo 10 > quota_ms + # echo 1000 > quota_reset_interval_ms + # echo 500 > wmarks_high + # echo 400 > wmarks_mid + # echo 200 > wmarks_low + # echo Y > enabled diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst index c976f3e33ffd..d14ba32f7788 100644 --- a/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst @@ -45,11 +45,7 @@ DAMON_RECLAIM找到在特定时间内没有被访问的内存区域并分页。 为了让系统管理员启用或禁用它，并为给定的系统进行调整，DAMON_RECLAIM利用了模块参数。也就 是说，你可以把 ``damon_reclaim.<parameter>=<value>`` 放在内核启动命令行上，或者把 -适当的值写入 ``/sys/modules/damon_reclaim/parameters/<parameter>`` 文件。 - -注意，除 ``启用`` 外的参数值只在DAMON_RECLAIM启动时应用。因此，如果你想在运行时应用新 -的参数值，而DAMON_RECLAIM已经被启用，你应该通过 ``启用`` 的参数文件禁用和重新启用它。 -在重新启用之前，应将新的参数值写入适当的参数值中。 +适当的值写入 ``/sys/module/damon_reclaim/parameters/<parameter>`` 文件。 下面是每个参数的描述。 @@ -218,7 +214,7 @@ nr_quota_exceeds 就开始真正的工作。如果DAMON_RECLAIM没有取得进展，因此空闲内存率低于20%，它会要求 DAMON_RECLAIM再次什么都不做，这样我们就可以退回到基于LRU列表的页面粒度回收了:: - # cd /sys/modules/damon_reclaim/parameters + # cd /sys/module/damon_reclaim/parameters # echo 30000000 > min_age # echo $((1 * 1024 * 1024 * 1024)) > quota_sz # echo 1000 > quota_reset_interval_ms diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst index 67d1b49481dc..bf21ff84f396 100644 --- a/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst @@ -34,16 +34,8 @@ https://github.com/awslabs/damo找到。下面的例子假设DAMO在你的$PATH上。当然，但 这并不是强制性的。 -因为DAMO使用的是DAMON的debugfs接口(详情请参考 :doc:`usage` 中的使用方法) 你应该 -确保debugfs被挂载。手动挂载它，如下所示:: - - # mount -t debugfs none /sys/kernel/debug/ - -或者在你的 ``/etc/fstab`` 文件中添加以下一行，这样你的系统就可以在启动时自动挂载 -debugfs了:: - - debugfs /sys/kernel/debug debugfs defaults 0 0 - +因为DAMO使用了DAMON的sysfs接口（详情请参考:doc:`usage`），你应该确保 +:doc:`sysfs </filesystems/sysfs>` 被挂载。 记录数据访问模式 ================ diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst index aeae2ab65dd8..17b9949d9b43 100644 --- a/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst @@ -46,10 +46,10 @@ DAMON的sysfs接口是在定义 ``CONFIG_DAMON_SYSFS`` 时建立的。它在其s 对于一个简短的例子，用户可以监测一个给定工作负载的虚拟地址空间，如下所示:: # cd /sys/kernel/mm/damon/admin/ - # echo 1 > kdamonds/nr && echo 1 > kdamonds/0/contexts/nr + # echo 1 > kdamonds/nr_kdamonds && echo 1 > kdamonds/0/contexts/nr_contexts # echo vaddr > kdamonds/0/contexts/0/operations - # echo 1 > kdamonds/0/contexts/0/targets/nr - # echo $(pidof <workload>) > kdamonds/0/contexts/0/targets/0/pid + # echo 1 > kdamonds/0/contexts/0/targets/nr_targets + # echo $(pidof <workload>) > kdamonds/0/contexts/0/targets/0/pid_target # echo on > kdamonds/0/state 文件层次结构 @@ -82,6 +82,9 @@ DAMON sysfs接口的文件层次结构如下图所示。在下图中，父子关 │ │ │ │ │ │ │ │ weights/sz_permil,nr_accesses_permil,age_permil │ │ │ │ │ │ │ watermarks/metric,interval_us,high,mid,low │ │ │ │ │ │ │ stats/nr_tried,sz_tried,nr_applied,sz_applied,qt_exceeds + │ │ │ │ │ │ │ tried_regions/ + │ │ │ │ │ │ │ │ 0/start,end,nr_accesses,age + │ │ │ │ │ │ │ │ ... │ │ │ │ │ │ ... │ │ │ │ ... │ │ ... @@ -111,7 +114,11 @@ kdamonds/<N>/ 读取 ``state`` 时，如果kdamond当前正在运行，则返回 ``on`` ，如果没有运行则返回 ``off`` 。 写入 ``on`` 或 ``off`` 使kdamond处于状态。向 ``state`` 文件写 ``update_schemes_stats`` ， 更新kdamond的每个基于DAMON的操作方案的统计文件的内容。关于统计信息的细节，请参考 -:ref:`stats section <sysfs_schemes_stats>`. +:ref:`stats section <sysfs_schemes_stats>`. 将 ``update_schemes_tried_regions`` 写到 +``state`` 文件，为kdamond的每个基于DAMON的操作方案，更新基于DAMON的操作方案动作的尝试区域目录。 +将`clear_schemes_tried_regions`写入`state`文件，清除kdamond的每个基于DAMON的操作方案的动作 +尝试区域目录。 关于基于DAMON的操作方案动作尝试区域目录的细节，请参考:ref:tried_regions 部分 +<sysfs_schemes_tried_regions>`。 如果状态为 ``on``，读取 ``pid`` 显示kdamond线程的pid。 @@ -186,6 +193,8 @@ regions/<N>/ 在每个区域目录中，你会发现两个文件（ ``start`` 和 ``end`` ）。你可以通过向文件写入 和从文件中读出，分别设置和获得初始监测目标区域的起始和结束地址。 +每个区域不应该与其他区域重叠。 目录“N”的“结束”应等于或小于目录“N+1”的“开始”。 + contexts/<N>/schemes/ --------------------- @@ -199,8 +208,8 @@ contexts/<N>/schemes/ schemes/<N>/ ------------ -在每个方案目录中，存在四个目录(``access_pattern``, ``quotas``,``watermarks``, -和 ``stats``)和一个文件(``action``)。 +在每个方案目录中，存在五个目录(``access_pattern``、``quotas``、``watermarks``、 +``stats`` 和 ``tried_regions``)和一个文件(``action``)。 ``action`` 文件用于设置和获取你想应用于具有特定访问模式的内存区域的动作。可以写入文件 和从文件中读取的关键词及其含义如下。 @@ -229,8 +238,8 @@ schemes/<N>/quotas/ 每个 ``动作`` 的最佳 ``目标访问模式`` 取决于工作负载，所以不容易找到。更糟糕的是，将某些动作 的方案设置得过于激进会造成严重的开销。为了避免这种开销，用户可以为每个方案限制时间和大小配额。 -具体来说，用户可以要求DAMON尽量只使用特定的时间（``时间配额``）来应用行动，并且在给定的时间间 -隔（``重置间隔``）内，只对具有目标访问模式的内存区域应用行动，而不使用特定数量（``大小配额``）。 +具体来说，用户可以要求DAMON尽量只使用特定的时间（``时间配额``）来应用动作，并且在给定的时间间 +隔（``重置间隔``）内，只对具有目标访问模式的内存区域应用动作，而不使用特定数量（``大小配额``）。 当预计超过配额限制时，DAMON会根据 ``目标访问模式`` 的大小、访问频率和年龄，对找到的内存区域 进行优先排序。为了进行个性化的优先排序，用户可以为这三个属性设置权重。 @@ -272,6 +281,24 @@ DAMON统计每个方案被尝试应用的区域的总数量和字节数，每个 你应该要求DAMON sysfs接口通过在相关的 ``kdamonds/<N>/state`` 文件中写入一个特殊的关键字 ``update_schemes_stats`` 来更新统计信息的文件内容。 +schemes/<N>/tried_regions/ +-------------------------- + +当一个特殊的关键字 ``update_schemes_tried_regions`` 被写入相关的 ``kdamonds/<N>/state`` +文件时，DAMON会在这个目录下创建从 ``0`` 开始命名的整数目录。每个目录包含的文件暴露了关于每个 +内存区域的详细信息，在下一个 :ref:`聚集区间 <sysfs_monitoring_attrs>`，相应的方案的 ``动作`` +已经尝试在这个目录下应用。这些信息包括地址范围、``nr_accesses`` 以及区域的 ``年龄`` 。 + +当另一个特殊的关键字 ``clear_schemes_tried_regions`` 被写入相关的 ``kdamonds/<N>/state`` +文件时，这些目录将被删除。 + +tried_regions/<N>/ +------------------ + +在每个区域目录中，你会发现四个文件(``start``, ``end``, ``nr_accesses``, and ``age``)。 +读取这些文件将显示相应的基于DAMON的操作方案 ``动作`` 试图应用的区域的开始和结束地址、``nr_accesses`` +和 ``年龄`` 。 + 用例 ~~~~ @@ -287,12 +314,12 @@ DAMON统计每个方案被尝试应用的区域的总数量和字节数，每个 # echo 1 > kdamonds/0/contexts/0/schemes/nr_schemes # cd kdamonds/0/contexts/0/schemes/0 # # set the basic access pattern and the action - # echo 4096 > access_patterns/sz/min - # echo 8192 > access_patterns/sz/max - # echo 0 > access_patterns/nr_accesses/min - # echo 5 > access_patterns/nr_accesses/max - # echo 10 > access_patterns/age/min - # echo 20 > access_patterns/age/max + # echo 4096 > access_pattern/sz/min + # echo 8192 > access_pattern/sz/max + # echo 0 > access_pattern/nr_accesses/min + # echo 5 > access_pattern/nr_accesses/max + # echo 10 > access_pattern/age/min + # echo 20 > access_pattern/age/max # echo pageout > action # # set quotas # echo 10 > quotas/ms @@ -311,6 +338,11 @@ DAMON统计每个方案被尝试应用的区域的总数量和字节数，每个 debugfs接口 =========== +.. note:: + + DAMON debugfs接口将在下一个LTS内核发布后被移除，所以用户应该转移到 + :ref:`sysfs接口<sysfs_interface>`。 + DAMON导出了八个文件, ``attrs``, ``target_ids``, ``init_regions``, ``schemes``, ``monitor_on``, ``kdamond_pid``, ``mk_contexts`` 和 ``rm_contexts`` under its debugfs directory, ``<debugfs>/damon/``. @@ -364,7 +396,7 @@ DAMON导出了八个文件, ``attrs``, ``target_ids``, ``init_regions``, 监测目标区域。 在这种情况下，用户可以通过在 ``init_regions`` 文件中写入适当的值，明确地设置他们想要的初 -始监测目标区域。输入的每一行应代表一个区域，形式如下:: +始监测目标区域。输入应该是一个由三个整数组成的队列，用空格隔开，代表一个区域的形式如下:: <target idx> <start address> <end address> @@ -376,9 +408,9 @@ DAMON导出了八个文件, ``attrs``, ``target_ids``, ``init_regions``, # cd <debugfs>/damon # cat target_ids 42 4242 - # echo "0 1 100 - 0 100 200 - 1 20 40 + # echo "0 1 100 \ + 0 100 200 \ + 1 20 40 \ 1 50 100" > init_regions 请注意，这只是设置了初始的监测目标区域。在虚拟内存监测的情况下，DAMON会在一个 ``更新间隔`` diff --git a/Documentation/translations/zh_CN/admin-guide/mm/index.rst b/Documentation/translations/zh_CN/admin-guide/mm/index.rst index 702271c5b683..a8fd2c4a8796 100644 --- a/Documentation/translations/zh_CN/admin-guide/mm/index.rst +++ b/Documentation/translations/zh_CN/admin-guide/mm/index.rst @@ -22,7 +22,7 @@ Linux内存管理是一个具有许多可配置设置的复杂系统, 且这些 .. _man 5 proc: http://man7.org/linux/man-pages/man5/proc.5.html Linux内存管理有它自己的术语，如果你还不熟悉它，请考虑阅读下面参考： -:ref:`Documentation/admin-guide/mm/concepts.rst <mm_concepts>`. +Documentation/admin-guide/mm/concepts.rst. 在此目录下，我们详细描述了如何与Linux内存管理中的各种机制交互。 diff --git a/Documentation/translations/zh_CN/admin-guide/mm/ksm.rst b/Documentation/translations/zh_CN/admin-guide/mm/ksm.rst index 4829156ef1ae..0029c4fd2201 100644 --- a/Documentation/translations/zh_CN/admin-guide/mm/ksm.rst +++ b/Documentation/translations/zh_CN/admin-guide/mm/ksm.rst @@ -146,3 +146,53 @@ stable_node_dups 比值 ``pages_sharing/pages_shared`` 的最大值受限制于 ``max_page_sharing`` 的设定。要想增加该比值，则相应地要增加 ``max_page_sharing`` 的值。 + +监测KSM的收益 +============= + +KSM可以通过合并相同的页面来节省内存，但也会消耗额外的内存，因为它需要生成一些rmap_items +来保存每个扫描页面的简要rmap信息。其中有些页面可能会被合并，但有些页面在被检查几次 +后可能无法被合并，这些都是无益的内存消耗。 + +1) 如何确定KSM在全系统范围内是节省内存还是消耗内存？这里有一个简单的近似计算方法供参考:: + + general_profit =~ pages_sharing * sizeof(page) - (all_rmap_items) * + sizeof(rmap_item); + + 其中all_rmap_items可以通过对 ``pages_sharing`` 、 ``pages_shared`` 、 ``pages_unshared`` + 和 ``pages_volatile`` 的求和而轻松获得。 + +2) 单一进程中KSM的收益也可以通过以下近似的计算得到:: + + process_profit =~ ksm_merging_pages * sizeof(page) - + ksm_rmap_items * sizeof(rmap_item). + + 其中ksm_merging_pages显示在 ``/proc/<pid>/`` 目录下，而ksm_rmap_items + 显示在 ``/proc/<pid>/ksm_stat`` 。 + +从应用的角度来看， ``ksm_rmap_items`` 和 ``ksm_merging_pages`` 的高比例意 +味着不好的madvise-applied策略，所以开发者或管理员必须重新考虑如何改变madvis策 +略。举个例子供参考，一个页面的大小通常是4K，而rmap_item的大小在32位CPU架构上分 +别是32B，在64位CPU架构上是64B。所以如果 ``ksm_rmap_items/ksm_merging_pages`` +的比例在64位CPU上超过64，或者在32位CPU上超过128，那么应用程序的madvise策略应 +该被放弃，因为ksm收益大约为零或负值。 + +监控KSM事件 +=========== + +在/proc/vmstat中有一些计数器，可以用来监控KSM事件。KSM可能有助于节省内存，这是 +一种权衡，因为它可能会在KSM COW或复制中的交换上遭受延迟。这些事件可以帮助用户评估 +是否或如何使用KSM。例如，如果cow_ksm增加得太快，用户可以减少madvise(, , MADV_MERGEABLE) +的范围。 + +cow_ksm + 在每次KSM页面触发写时拷贝（COW）时都会被递增，当用户试图写入KSM页面时， + 我们必须做一个拷贝。 + +ksm_swpin_copy + 在换入时，每次KSM页被复制时都会被递增。请注意，KSM页在换入时可能会被复 + 制，因为do_swap_page()不能做所有的锁，而需要重组一个跨anon_vma的KSM页。 + +-- +Izik Eidus, +Hugh Dickins, 2009年11月17日。 diff --git a/Documentation/translations/zh_CN/core-api/kernel-api.rst b/Documentation/translations/zh_CN/core-api/kernel-api.rst index c22662679065..a4b373c48c0c 100644 --- a/Documentation/translations/zh_CN/core-api/kernel-api.rst +++ b/Documentation/translations/zh_CN/core-api/kernel-api.rst @@ -48,6 +48,8 @@ lib/string_helpers.c 该API在以下内核代码中: +include/linux/fortify-string.h + lib/string.c include/linux/string.h @@ -119,6 +121,12 @@ include/linux/textsearch.h Linux中的CRC和数学函数 ====================== +算术溢出检查 +------------ + +该API在以下内核代码中: + +include/linux/overflow.h CRC函数 ------- @@ -166,8 +174,6 @@ include/asm-generic/div64.h include/linux/math64.h -lib/math/div64.c - lib/math/gcd.c UUID/GUID diff --git a/Documentation/translations/zh_CN/core-api/mm-api.rst b/Documentation/translations/zh_CN/core-api/mm-api.rst index a732b0eebf16..113359bdb7be 100644 --- a/Documentation/translations/zh_CN/core-api/mm-api.rst +++ b/Documentation/translations/zh_CN/core-api/mm-api.rst @@ -37,7 +37,7 @@ mm/gup.c 该API在以下内核代码中: -include/linux/gfp.h +include/linux/gfp_types.h Slab缓存 ======== diff --git a/Documentation/translations/zh_CN/core-api/workqueue.rst b/Documentation/translations/zh_CN/core-api/workqueue.rst index f6567cf9d3fb..6c1b5ec31d75 100644 --- a/Documentation/translations/zh_CN/core-api/workqueue.rst +++ b/Documentation/translations/zh_CN/core-api/workqueue.rst @@ -313,8 +313,8 @@ And with cmwq with ``@max_active`` >= 3, :: 第一个可以用追踪的方式进行跟踪: :: - $ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event - $ cat /sys/kernel/debug/tracing/trace_pipe > out.txt + $ echo workqueue:workqueue_queue_work > /sys/kernel/tracing/set_event + $ cat /sys/kernel/tracing/trace_pipe > out.txt (wait a few secs) 如果有什么东西在工作队列上忙着做循环，它就会主导输出，可以用工作项函数确定违规者。 diff --git a/Documentation/translations/zh_CN/dev-tools/kasan.rst b/Documentation/translations/zh_CN/dev-tools/kasan.rst index fe76cbe77ad6..05ef904dbcfb 100644 --- a/Documentation/translations/zh_CN/dev-tools/kasan.rst +++ b/Documentation/translations/zh_CN/dev-tools/kasan.rst @@ -90,6 +90,47 @@ KASAN只支持SLUB。 ``CONFIG_STACKTRACE`` 。要包括受影响物理页面的分配和释放堆栈跟踪的话， 请启用 ``CONFIG_PAGE_OWNER`` 并使用 ``page_owner=on`` 进行引导。 +启动参数 +~~~~~~~~ + +KASAN受到通用 ``panic_on_warn`` 命令行参数的影响。当它被启用时，KASAN +在打印出错误报告后会使内核恐慌。 + +默认情况下，KASAN只对第一个无效的内存访问打印错误报告。使用 +``kasan_multi_shot``，KASAN对每一个无效的访问都打印一份报告。这会禁用 +了KASAN报告的 ``panic_on_warn``。 + +另外，独立于 ``panic_on_warn`` 、 ``kasan.fault=`` boot参数可以用 +来控制恐慌和报告行为。 + +- ``kasan.fault=report`` 或 ``=panic`` 控制是否只打印KASAN report或 + 同时使内核恐慌（默认： ``report`` ）。即使 ``kasan_multi_shot`` 被 + 启用，恐慌也会发生。 + +基于软件和硬件标签的KASAN模式（见下面关于各种模式的部分）支持改变堆栈跟 +踪收集行为： + +- ``kasan.stacktrace=off`` 或 ``=on`` 禁用或启用分配和释放堆栈痕 + 迹的收集（默认： ``on`` ）。 + +- ``kasan.stack_ring_size=<number of entries>`` 指定堆栈环的条 + 目数（默认： ``32768`` ）。 + +基于硬件标签的KASAN模式是为了在生产中作为一种安全缓解措施使用。因此，它 +支持额外的启动参数，允许完全禁用KASAN或控制其功能。 + +- ``kasan=off`` 或 ``=on`` 控制KASAN是否被启用（默认： ``on`` ）。 + +- ``kasan.mode=sync``, ``=async`` or ``=asymm`` 控制KASAN是否 + 被配置为同步、异步或非对称的执行模式（默认： ``同步`` ）。 + 同步模式：当标签检查异常发生时，会立即检测到不良访问。 + 异步模式：不良访问的检测是延迟的。当标签检查异常发生时，信息被存储在硬 + 件中（对于arm64来说是在TFSR_EL1寄存器中）。内核周期性地检查硬件，并\ + 且只在这些检查中报告标签异常。 + 非对称模式：读取时同步检测不良访问，写入时异步检测。 + +- ``kasan.vmalloc=off`` or ``=on`` 禁用或启用vmalloc分配的标记（默认： ``on`` ）。 + 错误报告 ~~~~~~~~ @@ -194,39 +235,6 @@ slab对象的描述以及关于访问的内存页的信息。 通用KASAN还报告两个辅助调用堆栈跟踪。这些堆栈跟踪指向代码中与对象交互但不直接 出现在错误访问堆栈跟踪中的位置。目前，这包括 call_rcu() 和排队的工作队列。 -启动参数 -~~~~~~~~ - -KASAN受通用 ``panic_on_warn`` 命令行参数的影响。启用该功能后，KASAN在打印错误 -报告后会引起内核恐慌。 - -默认情况下，KASAN只为第一次无效内存访问打印错误报告。使用 ``kasan_multi_shot`` ， -KASAN会针对每个无效访问打印报告。这有效地禁用了KASAN报告的 ``panic_on_warn`` 。 - -另外，独立于 ``panic_on_warn`` , ``kasan.fault=`` 引导参数可以用来控制恐慌和报 -告行为: - -- ``kasan.fault=report`` 或 ``=panic`` 控制是只打印KASAN报告还是同时使内核恐慌 - (默认: ``report`` )。即使启用了 ``kasan_multi_shot`` ，也会发生内核恐慌。 - -基于硬件标签的KASAN模式（请参阅下面有关各种模式的部分）旨在在生产中用作安全缓解 -措施。因此，它支持允许禁用KASAN或控制其功能的附加引导参数。 - -- ``kasan=off`` 或 ``=on`` 控制KASAN是否启用 (默认: ``on`` )。 - -- ``kasan.mode=sync`` 、 ``=async`` 或 ``=asymm`` 控制KASAN是否配置 - 为同步或异步执行模式(默认:``sync`` )。 - 同步模式：当标签检查错误发生时，立即检测到错误访问。 - 异步模式：延迟错误访问检测。当标签检查错误发生时，信息存储在硬件中（在arm64的 - TFSR_EL1寄存器中）。内核会定期检查硬件，并且仅在这些检查期间报告标签错误。 - 非对称模式：读取时同步检测不良访问，写入时异步检测。 - -- ``kasan.vmalloc=off`` 或 ``=on`` 禁用或启用vmalloc分配的标记（默认：``on`` ）。 - -- ``kasan.stacktrace=off`` 或 ``=on`` 禁用或启用alloc和free堆栈跟踪收集 - (默认: ``on`` )。 - - 实施细则 -------- diff --git a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst index d6f2c65ed511..af65e7e93c02 100644 --- a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst +++ b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst @@ -132,3 +132,30 @@ Documentation/dev-tools/kcov.rst 是能够构建在内核之中，用于在每 不过要注意的是，静态分析工具存在**假阳性**的问题。在试图修复错误和警 告之前，需要仔细评估它们。 + +何时使用Sparse和Smatch +---------------------- + +Sparse做类型检查，例如验证注释的变量不会导致无符号的错误，检测 +``__user`` 指针使用不当的地方，以及分析符号初始化器的兼容性。 + +Smatch进行流程分析，如果允许建立函数数据库，它还会进行跨函数分析。 +Smatch试图回答一些问题，比如这个缓冲区是在哪里分配的？它有多大？这 +个索引可以由用户控制吗？这个变量比那个变量大吗？ + +一般来说，在Smatch中写检查比在Sparse中写检查要容易。尽管如此， +Sparse和Smatch的检查还是有一些重叠的地方。 + +Smatch和Coccinelle的强项 +------------------------ + +Coccinelle可能是最容易写检查的。它在预处理器之前工作，所以用Coccinelle +检查宏中的错误更容易。Coccinelle还能为你创建补丁，这是其他工具无法做到的。 + +例如，用Coccinelle你可以从 ``kmalloc_array(x, size, GFP_KERNEL)`` +到 ``kmalloc_array(x, size, GFP_KERNEL)`` 进行大规模转换，这真的很 +有用。如果你只是创建一个Smatch警告，并试图把转换的工作推给维护者，他们会很 +恼火。你将不得不为每个警告争论是否真的可以溢出。 + +Coccinelle不对变量值进行分析，而这正是Smatch的强项。另一方面，Coccinelle +允许你用简单的方法做简单的事情。 diff --git a/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst b/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst index 6399521d0548..74fa473bb504 100644 --- a/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst +++ b/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst @@ -358,9 +358,6 @@ GPIO 编号是无符号整数;IRQ 编号也是。这些构成了两个逻辑上 /* 映射 GPIO 编号到 IRQ 编号 */ int gpio_to_irq(unsigned gpio); - /* 映射 IRQ 编号到 GPIO 编号 (尽量避免使用) */ - int irq_to_gpio(unsigned irq); - 它们的返回值为对应命名空间的相关编号，或是负的错误代码(如果无法映射)。 (例如,某些 GPIO 无法做为 IRQ 使用。)以下的编号错误是未经检测的:使用一个 未通过 gpio_direction_input()配置为输入的 GPIO 编号，或者使用一个 @@ -373,10 +370,6 @@ gpio_to_irq()返回的非错误值可以传递给 request_irq()或者 free_irq() 触发选项是 IRQ 接口的一部分，如 IRQF_TRIGGER_FALLING，系统唤醒能力 也是如此。 -irq_to_gpio()返回的非错误值大多数通常可以被 gpio_get_value()所使用， -比如在 IRQ 是沿触发时初始化或更新驱动状态。注意某些平台不支持反映射,所以 -你应该尽量避免使用它。 - 模拟开漏信号 ------------ @@ -672,10 +665,6 @@ GPIO 控制器的路径类似 /sys/class/gpio/gpiochip42/ (对于从#42 GPIO /* gpio_export()的逆操作 */ void gpio_unexport(); - /* 创建一个 sysfs 连接到已导出的 GPIO 节点 */ - int gpio_export_link(struct device *dev, const char *name, - unsigned gpio) - 在一个内核驱动申请一个 GPIO 之后，它可以通过 gpio_export()使其在 sysfs 接口中可见。该驱动可以控制信号方向是否可修改。这有助于防止用户空间代码无意间 破坏重要的系统状态。 @@ -683,10 +672,6 @@ GPIO 控制器的路径类似 /sys/class/gpio/gpiochip42/ (对于从#42 GPIO 这个明确的导出有助于(通过使某些实验更容易来)调试，也可以提供一个始终存在的接口， 与文档配合作为板级支持包的一部分。 -在 GPIO 被导出之后，gpio_export_link()允许在 sysfs 文件系统的任何地方 -创建一个到这个 GPIO sysfs 节点的符号链接。这样驱动就可以通过一个描述性的 -名字，在 sysfs 中他们所拥有的设备下提供一个(到这个 GPIO sysfs 节点的)接口。 - API参考 ======= diff --git a/Documentation/translations/zh_CN/glossary.rst b/Documentation/translations/zh_CN/glossary.rst new file mode 100644 index 000000000000..24f094df97cd --- /dev/null +++ b/Documentation/translations/zh_CN/glossary.rst @@ -0,0 +1,36 @@ +.. SPDX-License-Identifier: GPL-2.0 + +术语表 +====== + +这不是一个完善的术语表，我们只是将有争议的和陌生的翻译词汇记录于此， +它的篇幅应该根据内核文档翻译的需求而增加。新词条最好随翻译补丁一起 +提交，且仅在以下情况下收录新词条： + + - 在翻译过程中遇到陌生词汇，且尚无翻译先例的； + - 在审阅过程中，针对某词条出现了不同的翻译意见； + - 使用频率不高的词条和首字母缩写类型的词条； + - 已经存在且有歧义的词条翻译。 + + +* atomic: 原子的，一般指不可中断的极小的临界区操作。 +* DVFS: 动态电压频率升降。（Dynamic Voltage and Frequency Scaling） +* EAS: 能耗感知调度。（Energy Aware Scheduling） +* flush: 刷新，一般指对cache的冲洗操作。 +* fork: 创建, 通常指父进程创建子进程。 +* futex: 快速用户互斥锁。（fast user mutex） +* guest halt polling: 客户机停机轮询机制。 +* HugePage: 巨页。 +* hypervisor: 虚拟机超级管理器。 +* memory barriers: 内存屏障。 +* MIPS: 每秒百万指令。（Millions of Instructions Per Second）,注意与mips指令集区分开。 +* mutex: 互斥锁。 +* NUMA: 非统一内存访问。 +* OpenCAPI: 开放相干加速器处理器接口。（Open Coherent Accelerator Processor Interface） +* OPP: 操作性能值。 +* overhead: 开销，一般指需要消耗的计算机资源。 +* PELT: 实体负载跟踪。（Per-Entity Load Tracking） +* sched domain: 调度域。 +* semaphores: 信号量。 +* spinlock: 自旋锁。 +* watermark: 水位，一般指页表的消耗水平。 diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index 3660a3451c86..7c3216845b71 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -133,6 +133,15 @@ TODOList: staging/index +术语表 +------ + +.. toctree:: + :maxdepth: 1 + + glossary + + 索引和表格 ---------- diff --git a/Documentation/translations/zh_CN/mm/highmem.rst b/Documentation/translations/zh_CN/mm/highmem.rst index f74800a6d9a7..2c0ee0cbf5c4 100644 --- a/Documentation/translations/zh_CN/mm/highmem.rst +++ b/Documentation/translations/zh_CN/mm/highmem.rst @@ -57,15 +57,29 @@ 在可行的情况下，这个函数应该比其他所有的函数优先使用。 - 这些映射是线程本地和CPU本地的，这意味着映射只能从这个线程中访问，并且当映射处于活动状 - 态时，该线程与CPU绑定。即使线程被抢占了（因为抢占永远不会被函数禁用），CPU也不能通过 - CPU-hotplug从系统中拔出，直到映射被处理掉。 + 这些映射是线程本地和CPU本地的，这意味着映射只能从这个线程中访问，并且当映射处于活跃状 + 态时，线程被绑定到CPU上。尽管这个函数从来没有禁用过抢占，但在映射被处理之前，CPU不能 + 通过CPU-hotplug从系统中拔出。 在本地的kmap区域中采取pagefaults是有效的，除非获取本地映射的上下文由于其他原因不允许 这样做。 + 如前所述，缺页异常和抢占从未被禁用。没有必要禁用抢占，因为当上下文切换到一个不同的任务 + 时，离开的任务的映射被保存，而进入的任务的映射被恢复。 + kmap_local_page()总是返回一个有效的虚拟地址，并且假定kunmap_local()不会失败。 + 在CONFIG_HIGHMEM=n的内核中，对于低内存页，它返回直接映射的虚拟地址。只有真正的高内 + 存页面才会被临时映射。因此，用户可以为那些已知不是来自ZONE_HIGHMEM的页面调用普通的 + page_address()。然而，使用kmap_local_page() / kunmap_local()总是安全的。 + + 虽然它比kmap()快得多，但在高内存的情况下，它对指针的有效性有限制。与kmap()映射相反， + 本地映射只在调用者的上下文中有效，不能传递给其他上下文。这意味着用户必须绝对保证返回 + 地址的使用只限于映射它的线程。 + + 大多数代码可以被设计成使用线程本地映射。因此，用户在设计他们的代码时，应该尽量避免使用 + kmap()，将页面映射到将被使用的同一线程中，并优先使用kmap_local_page()。 + 嵌套kmap_local_page()和kmap_atomic()映射在一定程度上是允许的（最多到KMAP_TYPE_NR）， 但是它们的调用必须严格排序，因为映射的实现是基于堆栈的。关于如何管理嵌套映射的细节， 请参见kmap_local_page() kdocs（包含在 "函数 "部分）。 diff --git a/Documentation/translations/zh_CN/mm/hmm.rst b/Documentation/translations/zh_CN/mm/hmm.rst index 5024a8a15516..babbbe756c0f 100644 --- a/Documentation/translations/zh_CN/mm/hmm.rst +++ b/Documentation/translations/zh_CN/mm/hmm.rst @@ -248,7 +248,7 @@ migrate_vma_finalize() 函数旨在使驱动程序更易于编写并集中跨驱 还有devm_request_free_mem_region(), devm_memremap_pages(), devm_memunmap_pages() 和 devm_release_mem_region() 当资源可以绑定到 ``struct device``. -整体迁移步骤类似于在系统内存中迁移 NUMA 页面(see :ref:`Page migration <page_migration>`) ， +整体迁移步骤类似于在系统内存中迁移 NUMA 页面(see Documentation/mm/page_migration.rst) ， 但这些步骤分为设备驱动程序特定代码和共享公共代码: 1. ``mmap_read_lock()`` diff --git a/Documentation/translations/zh_CN/mm/hugetlbfs_reserv.rst b/Documentation/translations/zh_CN/mm/hugetlbfs_reserv.rst index 752e5696cd47..c1fa35315d8b 100644 --- a/Documentation/translations/zh_CN/mm/hugetlbfs_reserv.rst +++ b/Documentation/translations/zh_CN/mm/hugetlbfs_reserv.rst @@ -15,7 +15,7 @@ Hugetlbfs 预留 概述 ==== -:ref:`hugetlbpage` 中描述的巨页通常是预先分配给应用程序使用的。如果VMA指 +Documentation/mm/hugetlbpage.rst 中描述的巨页通常是预先分配给应用程序使用的。如果VMA指 示要使用巨页，这些巨页会在缺页异常时被实例化到任务的地址空间。如果在缺页异常 时没有巨页存在，任务就会被发送一个SIGBUS，并经常不高兴地死去。在加入巨页支 持后不久，人们决定，在mmap()时检测巨页的短缺情况会更好。这个想法是，如果 @@ -142,14 +142,14 @@ HPAGE_RESV_OWNER标志被设置，以表明该VMA拥有预留。 消耗预留/分配一个巨页 =========================== -当与预留相关的巨页在相应的映射中被分配和实例化时，预留就被消耗了。该分配是在函数alloc_huge_page() +当与预留相关的巨页在相应的映射中被分配和实例化时，预留就被消耗了。该分配是在函数alloc_hugetlb_folio() 中进行的:: - struct page *alloc_huge_page(struct vm_area_struct *vma, + struct folio *alloc_hugetlb_folio(struct vm_area_struct *vma, unsigned long addr, int avoid_reserve) -alloc_huge_page被传递给一个VMA指针和一个虚拟地址，因此它可以查阅预留映射以确定是否存在预留。 -此外，alloc_huge_page需要一个参数avoid_reserve，该参数表示即使看起来已经为指定的地址预留了 +alloc_hugetlb_folio被传递给一个VMA指针和一个虚拟地址，因此它可以查阅预留映射以确定是否存在预留。 +此外，alloc_hugetlb_folio需要一个参数avoid_reserve，该参数表示即使看起来已经为指定的地址预留了 预留，也不应该使用预留。avoid_reserve参数最常被用于写时拷贝和页面迁移的情况下，即现有页面的额 外拷贝被分配。 @@ -162,7 +162,7 @@ vma_needs_reservation()返回的值通常为0或1。如果该地址存在预留 确定预留是否存在并可用于分配后，调用dequeue_huge_page_vma()函数。这个函数需要两个与预留有关 的参数： -- avoid_reserve，这是传递给alloc_huge_page()的同一个值/参数。 +- avoid_reserve，这是传递给alloc_hugetlb_folio()的同一个值/参数。 - chg，尽管这个参数的类型是long，但只有0或1的值被传递给dequeue_huge_page_vma。如果该值为0， 则表明存在预留（关于可能的问题，请参见 “预留和内存策略” 一节）。如果值 为1，则表示不存在预留，如果可能的话，必须从全局空闲池中取出该页。 @@ -179,7 +179,7 @@ free_huge_pages的值被递减。如果有一个与该页相关的预留，将 的剩余巨页和超额分配的问题。即使分配了一个多余的页面，也会进行与上面一样的基于预留的调整: SetPagePrivate(page) 和 resv_huge_pages--. -在获得一个新的巨页后，(page)->private被设置为与该页面相关的子池的值，如果它存在的话。当页 +在获得一个新的巨页后，(folio)->_hugetlb_subpool被设置为与该页面相关的子池的值，如果它存在的话。当页 面被释放时，这将被用于子池的计数。 然后调用函数vma_commit_reservation()，根据预留的消耗情况调整预留映射。一般来说，这涉及 @@ -199,7 +199,7 @@ SetPagePrivate(page)和resv_huge_pages-。 已经存在，所以不做任何改变。然而，如果共享映射中没有预留，或者这是一个私有映射，则必须创建 一个新的条目。 -在alloc_huge_page()开始调用vma_needs_reservation()和页面分配后调用 +在alloc_hugetlb_folio()开始调用vma_needs_reservation()和页面分配后调用 vma_commit_reservation()之间，预留映射有可能被改变。如果hugetlb_reserve_pages在共 享映射中为同一页面被调用，这将是可能的。在这种情况下，预留计数和子池空闲页计数会有一个偏差。 这种罕见的情况可以通过比较vma_needs_reservation和vma_commit_reservation的返回值来 diff --git a/Documentation/translations/zh_CN/mm/numa.rst b/Documentation/translations/zh_CN/mm/numa.rst index b15cfeeb6dfb..61fad89272fa 100644 --- a/Documentation/translations/zh_CN/mm/numa.rst +++ b/Documentation/translations/zh_CN/mm/numa.rst @@ -76,7 +76,7 @@ Linux将系统的硬件资源划分为多个软件抽象，称为“节点”。 系统管理员和应用程序设计者可以使用各种CPU亲和命令行接口，如taskset(1)和numactl(1)，以及程 序接口，如sched_setaffinity(2)，来限制任务的迁移，以改善NUMA定位。此外，人们可以使用 Linux NUMA内存策略修改内核的默认本地分配行为。 [见 -:ref:`Documentation/admin-guide/mm/numa_memory_policy.rst <numa_memory_policy>`]. +Documentation/admin-guide/mm/numa_memory_policy.rst]. 系统管理员可以使用控制组和CPUsets限制非特权用户在调度或NUMA命令和功能中可以指定的CPU和节点 的内存。 [见 Documentation/admin-guide/cgroup-v1/cpusets.rst] diff --git a/Documentation/translations/zh_CN/mm/page_owner.rst b/Documentation/translations/zh_CN/mm/page_owner.rst index 21a6a0837d42..b72a972271d9 100644 --- a/Documentation/translations/zh_CN/mm/page_owner.rst +++ b/Documentation/translations/zh_CN/mm/page_owner.rst @@ -34,20 +34,9 @@ page owner在默认情况下是禁用的。所以，如果你想使用它，你 一样进行。这两个不可能的分支应该不会影响到分配的性能，特别是在静态键跳转标签修补 功能可用的情况下。以下是由于这个功能而导致的内核代码大小的变化。 -- 没有page owner:: - - text data bss dec hex filename - 48392 2333 644 51369 c8a9 mm/page_alloc.o - -- 有page owner:: - - text data bss dec hex filename - 48800 2445 644 51889 cab1 mm/page_alloc.o - 6662 108 29 6799 1a8f mm/page_owner.o - 1025 8 8 1041 411 mm/page_ext.o - -虽然总共增加了8KB的代码，但page_alloc.o增加了520字节，其中不到一半是在hotpath -中。构建带有page owner的内核，并在需要时打开它，将是调试内核内存问题的最佳选择。 +尽管启用page owner会使内核的大小增加几千字节，但这些代码大部分都在页面分配器和 +热路径之外。构建带有page owner的内核，并在需要时打开它，将是调试内核内存问题的 +最佳选择。 有一个问题是由实现细节引起的。页所有者将信息存储到struct page扩展的内存中。这 个内存的初始化时间比稀疏内存系统中的页面分配器启动的时间要晚一些，所以，在初始化 @@ -62,7 +51,7 @@ page owner在默认情况下是禁用的。所以，如果你想使用它，你 1) 构建用户空间的帮助:: - cd tools/vm + cd tools/mm make page_owner_sort 2) 启用page owner: 添加 "page_owner=on" 到 boot cmdline. diff --git a/Documentation/translations/zh_CN/power/energy-model.rst b/Documentation/translations/zh_CN/power/energy-model.rst index c7da1b6aefee..48849919d8aa 100644 --- a/Documentation/translations/zh_CN/power/energy-model.rst +++ b/Documentation/translations/zh_CN/power/energy-model.rst @@ -23,15 +23,15 @@ 实现支持，EM框架作为一个抽象层介入，它在内核中对功率成本表的格式进行标准化， 因此能够避免多余的工作。 -功率值可以用毫瓦或“抽象刻度”表示。多个子系统可能使用EM，由系统集成商来检查 +功率值可以用微瓦或“抽象刻度”表示。多个子系统可能使用EM，由系统集成商来检查 功率值刻度类型的要求是否满足。可以在能量感知调度器的文档中找到一个例子 Documentation/scheduler/sched-energy.rst。对于一些子系统，比如热能或 powercap，用“抽象刻度”描述功率值可能会导致问题。这些子系统对过去使用的功率的 -估算值更感兴趣，因此可能需要真实的毫瓦。这些要求的一个例子可以在智能功率分配 +估算值更感兴趣，因此可能需要真实的微瓦。这些要求的一个例子可以在智能功率分配 Documentation/driver-api/thermal/power_allocator.rst文档中找到。 内核子系统可能（基于EM内部标志位）实现了对EM注册设备是否具有不一致刻度的自动 -检查。要记住的重要事情是，当功率值以“抽象刻度”表示时，从中推导以毫焦耳为单位 +检查。要记住的重要事情是，当功率值以“抽象刻度”表示时，从中推导以微焦耳为单位 的真实能量消耗是不可能的。 下图描述了一个驱动的例子（这里是针对Arm的，但该方法适用于任何体系结构），它 @@ -89,20 +89,40 @@ Documentation/driver-api/thermal/power_allocator.rst文档中找到。 驱动程序应通过以下API将性能域注册到EM框架中:: int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states, - struct em_data_callback *cb, cpumask_t *cpus, bool milliwatts); + struct em_data_callback *cb, cpumask_t *cpus, bool microwatts); 驱动程序必须提供一个回调函数，为每个性能状态返回<频率,功率>元组。驱动程序 提供的回调函数可以自由地从任何相关位置（DT、固件......）以及以任何被认为是 必要的方式获取数据。只有对于CPU设备，驱动程序必须使用cpumask指定性能域的CPU。 对于CPU以外的其他设备，最后一个参数必须被设置为NULL。 -最后一个参数“milliwatts”（毫瓦）设置成正确的值是很重要的，使用EM的内核 +最后一个参数“microwatts”（微瓦）设置成正确的值是很重要的，使用EM的内核 子系统可能会依赖这个标志来检查所有的EM设备是否使用相同的刻度。如果有不同的 -刻度，这些子系统可能决定：返回警告/错误，停止工作或崩溃（panic）。 +刻度，这些子系统可能决定返回警告/错误，停止工作或崩溃（panic）。 关于实现这个回调函数的驱动程序的例子，参见第3节。或者在第2.4节阅读这个API 的更多文档。 +使用DT的EM注册 +============== + +EM也可以使用OPP框架和DT "操作点-v2 "中的信息注册。DT中的每个OPP条目都可 +以用一个包含微瓦特功率值的属性 "op-microwatt "来扩展。这个OPP DT属性允 +许平台注册反映总功率（静态+动态）的EM功率值。这些功率值可能直接来自实验和 +测量。 + +“人工”EM的注册 +============== + +有一个选项可以为缺少关于每个性能状态的功率值的详细知识的驱动程序提供一个自 +定义回调。回调.get_cost()是可选的，它提供EAS使用的“成本”值。这对那些只提 +供CPU类型之间相对效率信息的平台很有用，人们可以利用这些信息来创建一个抽象的 +功率模型。但是，考虑到输入功率值的大小限制，即使是抽象的功率模型有时也很难装 +进去。.get_cost()允许提供反映CPU效率的“成本”值。这将允许提供EAS信息，它 +与EM内部计算'成本'值的公式有不同的关系。要为这样的平台注册EM，驱动程序必须 +将标志“microwatts”设置为0，提供.get_power()回调和.get_cost()回调。EM +框架会在注册过程中正确处理这样的平台。这种平台会被设置EM_PERF_DOMAIN_ARTIFICIAL +标志。其他使用EM的框架应该特别注意测试和正确对待这个标志。 “简单”EM的注册 ~~~~~~~~~~~~~~~~ @@ -147,8 +167,8 @@ cpufreq_driver::register_em()。这个回调必须为每个特定的驱动程序 -> drivers/cpufreq/foo_cpufreq.c - 01 static int est_power(unsigned long *mW, unsigned long *KHz, - 02 struct device *dev) + 01 static int est_power(struct device *dev, unsigned long *mW, + 02 unsigned long *KHz) 03 { 04 long freq, power; 05 diff --git a/Documentation/translations/zh_CN/process/howto.rst b/Documentation/translations/zh_CN/process/howto.rst index 888978a62db3..10254751df6a 100644 --- a/Documentation/translations/zh_CN/process/howto.rst +++ b/Documentation/translations/zh_CN/process/howto.rst @@ -254,7 +254,7 @@ Linux-next 集成测试树 https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git 通过这种方式，Linux-next 对下一个合并阶段将进入主线内核的内容给出了一个概要 -展望。非常欢冒险的测试者运行测试Linux-next。 +展望。非常欢迎冒险的测试者运行测试Linux-next。 多个主要版本的稳定版内核树 ----------------------------------- diff --git a/Documentation/translations/zh_TW/gpio.txt b/Documentation/translations/zh_TW/gpio.txt index e3c076dd75a5..1b986bbb0909 100644 --- a/Documentation/translations/zh_TW/gpio.txt +++ b/Documentation/translations/zh_TW/gpio.txt @@ -363,9 +363,6 @@ GPIO 編號是無符號整數;IRQ 編號也是。這些構成了兩個邏輯上 /* 映射 GPIO 編號到 IRQ 編號 */ int gpio_to_irq(unsigned gpio); - /* 映射 IRQ 編號到 GPIO 編號 (儘量避免使用) */ - int irq_to_gpio(unsigned irq); - 它們的返回值爲對應命名空間的相關編號，或是負的錯誤代碼(如果無法映射)。 (例如,某些 GPIO 無法做爲 IRQ 使用。)以下的編號錯誤是未經檢測的:使用一個 未通過 gpio_direction_input()配置爲輸入的 GPIO 編號，或者使用一個 @@ -378,10 +375,6 @@ gpio_to_irq()返回的非錯誤值可以傳遞給 request_irq()或者 free_irq() 觸發選項是 IRQ 接口的一部分，如 IRQF_TRIGGER_FALLING，系統喚醒能力 也是如此。 -irq_to_gpio()返回的非錯誤值大多數通常可以被 gpio_get_value()所使用， -比如在 IRQ 是沿觸發時初始化或更新驅動狀態。注意某些平台不支持反映射,所以 -你應該儘量避免使用它。 - 模擬開漏信號 ---------------------------- @@ -634,18 +627,9 @@ GPIO 控制器的路徑類似 /sys/class/gpio/gpiochip42/ (對於從#42 GPIO /* gpio_export()的逆操作 */ void gpio_unexport(); - /* 創建一個 sysfs 連接到已導出的 GPIO 節點 */ - int gpio_export_link(struct device *dev, const char *name, - unsigned gpio) - 在一個內核驅動申請一個 GPIO 之後，它可以通過 gpio_export()使其在 sysfs 接口中可見。該驅動可以控制信號方向是否可修改。這有助於防止用戶空間代碼無意間 破壞重要的系統狀態。 這個明確的導出有助於(通過使某些實驗更容易來)調試，也可以提供一個始終存在的接口， 與文檔配合作爲板級支持包的一部分。 - -在 GPIO 被導出之後，gpio_export_link()允許在 sysfs 文件系統的任何地方 -創建一個到這個 GPIO sysfs 節點的符號連結。這樣驅動就可以通過一個描述性的 -名字，在 sysfs 中他們所擁有的設備下提供一個(到這個 GPIO sysfs 節點的)接口。 - |