| /linux/Documentation/translations/sp_SP/scheduler/ |
| H A D | sched-bwc.rst | 16 El control de ancho de banda es una extensión CONFIG_FAIR_GROUP_SCHED que
17 permite especificar el máximo uso disponible de CPU para un grupo o una jerarquía.
19 El ancho de banda permitido para un grupo de tareas se especifica usando una
34 cantidad transferida en cada una de esas actualizaciones es ajustable y
41 devolver, con el coste de una mayor interferencia hacia los otros usuarios
50 por cada segundo de tiempo de reloj de una tarea, tendríamos que
56 La característica de ráfaga implica que el trabajo de una tarea no siempre
58 como una distribución estadística.
67 cada sobre-ejecución se empareja con una infra-ejecución en tanto x esté
76 en medio, hay un umbral donde una tarea excede su tiempo límite de
[all …]
|
| H A D | sched-design-CFS.rst | 22 El 80% del diseño de CFS puede ser resumido en una única frase: CFS
23 básicamente modela una "CPU ideal, precisa y multi-tarea" sobre hardware
26 "una CPU multitarea ideal" es una CPU (inexistente :-)) que tiene un 100%
28 velocidad, en paralelo, y cada una a 1/n velocidad. Por ejemplo, si hay dos
29 tareas ejecutándose, entonces cada una usa un 50% de la potencia --- es decir,
32 En hardware real, se puede ejecutar una única tarea a la vez, así que
34 de ejecución virtual de una tarea específica cuando la siguiente porción
36 En la práctica, el tiempo de ejecución virtual de una tarea es el
47 de CPU esperado" que una tarea debería tener.
71 de datos para las colas de ejecución (en inglés "runqueues"), pero usa una
[all …]
|
| H A D | sched-eevdf.rst | 12 First", fue presentado por primera vez en una publicación científica en
14 versión 6.6 (y como una nueva opción en 2024), alejándose del gestor
15 de tareas CFS, en favor de una versión de EEVDF propuesta por Peter
23 para determinar si una tarea ha recibido su cantidad justa de tiempo
24 de ejecución en la CPU. De esta manera, una tarea con un "retraso"
25 positivo, es porque se le debe tiempo de ejecución, mientras que una
29 deadline) para cada una, eligiendo la tarea con la VD más próxima para
40 reajustar su retraso negativo: cuando una tarea duerme, esta permanece en
|
| /linux/Documentation/translations/it_IT/process/ |
| H A D | 5.Posting.rst | 12 presentato alla comunità per una revisione ed eventualmente per la sua
26 C'è sempre una certa resistenza nel pubblicare patch finché non sono
28 Ma quando il lavoro è di una certa complessità, c'è molto da guadagnare
64 con una licenza GPL
70 Preparazione di una patch
73 La preparazione delle patch per la pubblicazione può richiedere una quantità
77 Le patch devono essere preparate per una specifica versione del kernel.
78 Come regola generale, una patch dovrebbe basarsi sul ramo principale attuale
84 Per facilitare una revisione e una verifica più estesa, potrebbe diventare
91 Solo le modifiche più semplici dovrebbero essere preparate come una singola
[all …]
|
| H A D | 6.Followthrough.rst | 13 l'aggiunta delle vostre capacità ingegneristiche, avete pubblicato una serie
17 simboleggia una transizione alla fase successiva del processo, con,
20 È raro che una modifica sia così bella alla sua prima pubblicazione che non
32 Una patch che abbia una certa rilevanza avrà ricevuto numerosi commenti
40 scriverla. Ma tale valore non li tratterrà dal porvi una domanda
51 fatti ancora e ancora. Se ricevete una revisione che vi sembra abbia
67 nel vostro driver per aggirare un problema deve diventare una caratteristica
82 su di una modifica suggerita, spiegatela inserendo anche la vostra soluzione
103 l'ultima volta. Quindi è sempre una buona idea quella di ricordare ai
113 una decisione. Se credete veramente che tale decisione andrà contro di voi
[all …]
|
| H A D | coding-style.rst | 18 La prima cosa che suggerisco è quella di stamparsi una copia degli standard
48 subordinati ``case``. In questo modo si evita una doppia indentazione per
120 allineare i nuovi pezzi alla parentesi aperta di una funzione.
122 Lo stesso si applica, nei file d'intestazione, alle funzioni con una
135 una strategia di posizionamento o un'altra; ma il modo qui preferito,
138 di chiusura per prima su una nuova riga, così:
177 Notate che la graffa di chiusura è da sola su una riga propria, ad
204 righe sul vostro schermo non sono una risorsa illimitata (pensate ad uno
208 Non usate inutilmente le graffe dove una singola espressione è sufficiente.
225 contiene una sola espressione; in quest'ultimo caso usate le graffe per
[all …]
|
| H A D | howto.rst | 35 Per lo sviluppo kernel è richiesta una buona conoscenza del linguaggio C.
47 Sebbene si attenga allo standard ISO C11, esso utilizza una serie di
81 I sorgenti del kernel Linux hanno una vasta base di documenti che vi
86 con lo spazio utente, è raccomandabile che inviate una notifica o una
91 Di seguito una lista di file che sono presenti nei sorgente del kernel e che
95 Questo file da una piccola anteprima del kernel Linux e descrive il
101 Questo file fornisce una lista dei pacchetti software necessari
114 Questo file descrive dettagliatamente come creare ed inviare una patch
162 kernel, e spiega cosa fare se si vuole che una modifica venga inserita
171 Una buona introduzione che descrivere esattamente cos'è una patch e come
[all …]
|
| H A D | 4.Coding.rst | 31 praticamente informativa. Ne risulta che ci sia una quantità sostanziale di
41 quanto il kernel richiede una certa uniformità, in modo da rendere possibile
42 per gli sviluppatori una comprensione veloce di ogni sua parte. Non ci sono,
57 una fredda accoglienza. Di conseguenza è meglio evitare questo tipo di patch.
61 Il documento sullo stile del codice non dovrebbe essere letto come una legge
63 (per esempio, una linea che diviene poco leggibile se divisa per rientrare
67 le regole, per una riformattazione automatica e veloce del vostro codice
89 al pari di una prematura ottimizzazione. L'astrazione dovrebbe essere usata
92 Ad un livello base, considerate una funzione che ha un argomento che viene
108 D'altro canto, se vi ritrovate a dover copiare una quantità significativa di
[all …]
|
| H A D | adding-syscalls.rst | 8 Aggiungere una nuova chiamata di sistema
20 La prima considerazione da fare quando si aggiunge una nuova chiamata di
50 Tuttavia, :manpage:`fcntl(2)` è una chiamata di sistema multiplatrice che
51 nasconde una notevole complessità, quindi è ottima solo quando la nuova
91 argomenti, il modo migliore è quello di incapsularne la maggior parte in una
106 - un vecchio kernel può gestire l'accesso di una versione moderna di un
110 - un nuovo kernel può gestire l'accesso di una versione vecchia di un
124 accesso da spazio utente quando il kernel ha già dei meccanismi e una semantica
134 ``O_CLOEXEC`` dato che è specifico dell'architettura e fa parte di una
148 dovreste anche considerare se non sia più appropriata una versione
[all …]
|
| H A D | stable-kernel-rules.rst | 14 - Questa patch o una equivalente deve esistere già nei sorgenti principali di
23 - Corregge un problema come un oops, un blocco, una corruzione di dati, un
24 vero problema di sicurezza, una stranezza hardware, un problema di
27 - Problemi importanti riportati dagli utenti di una distribuzione potrebbero
30 correzione ha un'alta probabilità d'introdurre una regressione,
35 come una teorica sezione critica, senza aver fornito anche una spiegazione
48 Ci sono tre opzioni per inviare una modifica per i sorgenti -stable:
52 2. Chiedere alla squadra "stable" di prendere una patch già applicata sui
54 3. Sottomettere una patch alla squadra "stable" equivalente ad una modifica già
68 o una equivalente sia applicabile, o già presente in tutti i sorgenti
[all …]
|
| H A D | 2.Process.rst | 12 un numero di utenti e sviluppatori relativamente basso. Con una base
15 lo sviluppo più agevole. È richiesta una solida conoscenza di come tale
41 Viene seguita una disciplina abbastanza lineare per l'inclusione delle
65 consentita una modifica più consistente, ma tali occasioni sono rare.
77 kernel -rc circa una volta alla settimana; e ne usciranno circa 6 o 9 prima
99 creare quindi una rilascio stabile? Un metro valido è il numero di regressioni
102 particolarmente seri. Per questa ragione, le modifiche che portano ad una
112 regressioni al giro successivo. Quindi molti kernel 5.x escono con una
119 considerazione per un rilascio d'aggiornamento, una modifica deve:
150 Il ciclo di vita di una patch
[all …]
|
| H A D | submitting-patches.rst | 11 Una persona o un'azienda che volesse inviare una patch al kernel potrebbe
13 una certa familiarità col "sistema". Questo testo è una raccolta di
20 Documentation/translations/it_IT/process/submit-checklist.rst per una lista di
55 ha fare il vostro lavoro, che sia la correzione di un baco da una riga o una
65 sorgenti stabili o dai sorgenti di una distribuzione particolare che prende
69 un incidente di sistema, prestazioni di una regressione, picchi di latenza,
95 Quando inviate o rinviate una patch o una serie, includete la descrizione
127 riferimento. Se la patch è il risultato di una discussione avvenuta
132 quest'etichetta per fare riferimento ad un rapporto su una lista di discussione
134 riferimento ad una discussione precedentemente avvenuta su una lista di
[all …]
|
| /linux/Documentation/translations/sp_SP/process/ |
| H A D | adding-syscalls.rst | 8 Agregando una Nueva Llamada del Sistema
11 Este documento describe qué involucra agregar una nueva llamada del sistema
19 La primera cosa a considerar cuando se agrega una llamada al sistema es si
46 Evite agregar cualquier API a debugfs, ya que no se considera una
51 podría ser más apropiada. Sin embargo, :manpage:`fcntl(2)` es una
69 ser soportada indefinidamente. Como tal, es una muy buena idea discutir
93 argumentos, es preferible encapsular la mayoría de los argumentos en una
114 un kernel más nuevo, el código del kernel puede extender con ceros, una
153 debería considerar también si una versión xyzzyat(2) es mas
161 efectivamente dando una operación fxyzzy(3) gratis::
[all …]
|
| H A D | maintainer-kvm-x86.rst | 11 KVM se esfuerza por ser una comunidad acogedora; las contribuciones de los
36 improbable caso de que una corrección para el ciclo actual se dirija a
49 de una rama temática no tiene impacto en los hashes SHA1 de otros commit
50 en en camino, y tener que rechazar una solicitud de pull debido a errores
55 decir, cuando se actualiza una rama temática. Como resultado, los push
92 Los pings para obtener una actualización del estado son bienvenidos, pero
95 no sólo para obtener comentarios o una actualización, por favor haga todo
110 versión actual. No hay una regla única, pero normalmente sólo las
115 necesidad de seleccionar una rama temática específica como base. Si hay
120 parche/serie es una serie multi-arquitectura, es decir, tiene
[all …]
|
| H A D | coding-style.rst | 17 En primer lugar, sugeriría imprimir una copia de los estándares de código
37 el código se mueva demasiado a la derecha y dificulta la lectura en una
46 La forma preferida de facilitar múltiples niveles de sangría en una
70 No ponga varias declaraciones en una sola línea a menos que tenga algo que
94 Tampoco ponga varias asignaciones en una sola línea. El estilo de código
111 El límite preferido en la longitud de una sola línea es de 80 columnas.
121 Estas mismas reglas se aplican a los encabezados de funciones con una larga
133 técnicas para elegir una estrategia de ubicación sobre la otra, pero la
176 **excepto** en los casos en que es seguida por una continuación de la misma
177 declaración, es decir, un ``while`` en una sentencia do o un ``else`` en
[all …]
|
| H A D | 4.Coding.rst | 33 casos, orientativas. Como resultado, hay una cantidad considerable de
55 pueden comenzar a generar parches de reformateo como una forma de
56 familiarizarse con el proceso o como una forma de incluir su nombre en los
59 desarrollo; tienden a recibir una recepción adversa. Por lo tanto, este
60 tipo de parche es mejor evitarlo. Es natural corregir el estilo de una
64 El documento de estilo de programación tampoco debe leerse como una ley
65 absoluta que nunca puede transgredirse. Si hay una buena razón para ir en
66 contra del estilo (una línea que se vuelve mucho menos legible si se divide
90 experiencia ha demostrado que una abstracción excesiva o prematura puede
94 A un nivel simple, considere una función que tiene un argumento que siempre
[all …]
|
| H A D | 6.Followthrough.rst | 12 sumado a sus propias habilidades de ingeniería, ha resultado en una serie
15 trabajo ya está hecho. En verdad, publicar parches indica una transición a
30 Un parche de cualquier importancia resultará en una serie de comentarios de
38 hacer una pregunta fundamental: ¿cómo será mantener un kernel con este
42 seguirá existiendo y en desarrollo dentro de una década.
44 - La revisión de código es un trabajo arduo y es una ocupación
48 los mismos errores repetirse una y otra vez. Si recibe una revisión que
65 …sas con una apariencia uniforme. A veces, esto significa que el truco ingenioso en su driver para …
77 explique lo que realmente está sucediendo. Si tiene una objeción técnica a
99 que siempre es una buena idea recordarles sobre problemas planteados
[all …]
|
| H A D | 7.AdvancedTopics.rst | 11 Llegados a este punto, con suerte, tiene una idea de cómo funciona el
14 que desean convertirse en una parte regular del proceso de desarrollo del
24 El control de versiones distribuido permitió una aceleración inmediata
32 es una herramienta joven y poderosa que aún está siendo civilizada por
48 capaz de obtener una copia del repositorio mainline, explorar el historial
66 obtener una cuenta en kernel.org, pero no son fáciles de conseguir; ver
70 línea de desarrollo puede separarse en una “rama temática” separada y
84 se pueden transferir de manera transparente de una rama a otra. Y así
90 de una simple obsesión por crear la historia perfecta del proyecto.
94 si no tienen una vista compartida del historial del proyecto; si reescribe
[all …]
|
| H A D | 5.Posting.rst | 25 Hay una tentación constante de evitar publicar parches antes de que
35 una buena idea decirlo en la propia publicación. Además, mencione
70 La preparación de parches para su publicación puede ser una cantidad
71 sorprendente de trabajo, pero, una vez más, intentar ahorrar tiempo aquí
74 Los parches deben prepararse contra una versión específica del kernel.
77 con un punto de lanzamiento bien conocido, una versión estable o -rc, en
83 un parche en estos otros árboles puede requerir una cantidad significativa
87 lo demás debe hacerse como una serie lógica de cambios. Dividir parches
103 de una descripción de una línea. Cada parche debe hacer un cambio
115 parcial de una serie de parches es un escenario común cuando se
[all …]
|
| H A D | 2.Process.rst | 13 desarrolladores involucrados. Con una base de usuarios en los millones y
16 problemas. Se requiere una comprensión solida de cómo funciona el proceso
17 para ser una parte efectiva del mismo.
43 Se sigue una disciplina relativamente sencilla con respecto a la fusión
70 suelen recibir una recepción poco amistosa. Como regla general, si se
71 pierde la ventana de fusión de una característica determinada, lo mejor
72 que puede hacer es esperar al siguiente ciclo de desarrollo. (Se hace una
79 aproximadamente una vez a la semana; una serie normal llegará a algún
149 La selección de un kernel para soporte a largo plazo es puramente una
167 cómo un parche entra en el kernel. Lo que sigue a continuación es una
[all …]
|
| H A D | handling-regressions.rst | 15 al menos una lectura rápida del mismo antes de continuar.
35 como ``#regzbot introduced v5.13..v5.14-rc1``. Si no, mandar una
55 #. Intente arreglar las regresiones rápidamente una vez la causa haya sido
92 así, envíe una respuesta (con la lista de regresiones en CC) con un
141 Todo esto se espera y es importante en una regresión, ya que estas
145 desarrolladores del kernel o distribuciones de Linux; una de esas
155 usuarios situaciones donde una regresión les deje solo tres opciones:
157 * Ejecutar el kernel con una regresión que afecta seriamente al uso.
159 * Cambiar a un kernel nuevo o mas antiguo -- rebajarse a una versión
162 * Continuar ejecutando una versión desfasada y potencialmente insegura del
[all …]
|
| /linux/Documentation/translations/it_IT/doc-guide/ |
| H A D | kernel-doc.rst | 38 È considerata una buona pratica quella di fornire una documentazione formattata
41 inoltre, di fornire una documentazione kernel-doc anche per procedure private
42 (ovvero, dichiarate "static") al fine di fornire una struttura più coerente
43 dei sorgenti. Quest'ultima raccomandazione ha una priorità più bassa ed è a
52 Cerchiamo anche di fornire una documentazione formattata secondo kernel-doc
56 Raccomandiamo, inoltre, di fornire una documentazione formattata con kernel-doc
58 una struttura più coerente dei sorgenti. Questa raccomandazione ha una priorità
71 su una riga separata.
121 un argomento, una linea di commento vuota, oppure la fine del commento.
126 Ogni argomento di una funzione dovrebbe essere descritto in ordine, subito
[all …]
|
| /linux/Documentation/translations/sp_SP/ |
| H A D | memory-barriers.txt | 30 Este documento no es una especificación; es intencionalmente (por motivos
32 pretende ser una guía para usar las diversas barreras de memoria
39 De nuevo, este documento no es una especificación de lo que Linux espera
47 (2) proporcionar una guía sobre cómo utilizar las barreras disponibles.
49 Tenga en cuenta que una arquitectura puede proporcionar más que el
53 Tenga en cuenta también que es posible que una barrera no valga (sea no-op)
153 relajado, y una CPU en realidad puede realizar las operaciones de memoria
194 Además, los stores asignados por una CPU al sistema de memoria pueden no
206 Aquí hay una dependencia obvia de la dirección, ya que el valor cargado en
222 de control es muy importante. Por ejemplo, imagine una tarjeta ethernet con
[all …]
|
| H A D | index.rst | 23 La propagación simultánea de la traducción de una modificación en
26 es posible. Por tanto, no existe ninguna garantía de que una traducción
27 esté actualizada con las últimas modificaciones. Si lo que lee en una
32 Una traducción no es una * bifurcación * de la documentación oficial, por
43 gramática, y una cultura tras ella, por lo tanto, la traducción de una
52 obtener una traducción.
58 suponer una gran barrera para hablantes de distintas versiones del español,
66 la falta de una traducción o de un grupo de traducciones.
|
| /linux/Documentation/translations/it_IT/kernel-hacking/ |
| H A D | hacking.rst | 48 l'un l'altro, ma a parte questo esiste una gerarchia rigida: ognuno di questi
50 softirq è in esecuzione su d'una CPU, nessun altro softirq può avvicendarsi
60 Ci si trova nel contesto utente quando si arriva da una chiamata di sistema
86 garantisce che questi gestori non vengano mai interrotti: se una stessa
91 programmare una 'interruzione software' per l'esecuzione e quindi terminare.
93 Potete dire d'essere in una interruzione hardware perché in_hardirq()
104 Quando una chiamata di sistema sta per tornare allo spazio utente,
155 lo stato dell'FPU (ed evitare cambi di contesto). Generalmente è una
195 All'interno di una ioctl vi trovate nel contesto utente di un processo. Quando
207 della manipolazione di una struttura dati.
[all …]
|