| /Documentation/translations/sp_SP/ |
| D | index.rst | 19 simplemente para aquellos que prefieran leer en el idioma español. Sin
20 embargo, tenga en cuenta que la *única* documentación oficial es la que
21 está en inglés: :ref:`linux_doc`
23 La propagación simultánea de la traducción de una modificación en
25 de la traducción intentan mantener sus traducciones al día, en tanto les
27 esté actualizada con las últimas modificaciones. Si lo que lee en una
28 traducción no se corresponde con lo que ve en el código fuente, informe
29 al maintainer de la traducción y, si puede, consulte la documentación en
35 contenidos deberá ser realizada anteriormente en los documentos en inglés.
45 razón, cuando lea esta traducción, puede encontrar algunas diferencias en
[all …]
|
| D | memory-barriers.txt | 13 BARRERAS DE MEMORIA EN EL KERNEL LINUX
23 traducción, la única referencia válida es la documentación oficial en
35 consistencia de memoria formal y documentación en tools/memory-model/. Sin
37 sus maintainers en lugar de que como un oráculo infalible.
44 (1) especificar la funcionalidad mínima en la que se puede confiar para
45 cualquier barrera en concreto, y
49 Tenga en cuenta que una arquitectura puede proporcionar más que el
50 requisito mínimo para cualquier barrera en particular, pero si la
53 Tenga en cuenta también que es posible que una barrera no valga (sea no-op)
54 para alguna arquitectura porque por la forma en que funcione dicha
[all …]
|
| /Documentation/translations/sp_SP/process/ |
| D | 2.Process.rst | 13 desarrolladores involucrados. Con una base de usuarios en los millones y
23 en el tiempo de manera flexible, con uno nuevo lanzamiento principal del
37 características, cambios internos en la API y más. Un lanzamiento típico
38 puede contener alrededor de 13,000 conjuntos de cambios incluyendo en
45 se dice que la "merge window" (ventana de fusión) está abierta. En ese
47 aceptado por la comunidad de desarrollo) se fusiona en el kernel mainline.
55 y montados con anticipación. Como funciona ese proceso se describirá en
67 problemas deben enviarse al mainline. En ocasiones, se permitirá un cambio
74 anteriormente; si no afectan a ningún código en árbol, no pueden causar
75 regresiones y debería ser seguro agregarlos en cualquier momento).
[all …]
|
| D | 1.Intro.rst | 19 comunidad en muchas formas, y la capacidad de influir en la dirección del
25 (merge window). Se cubren las distintas fases en el desarrollo del parche,
31 :ref:`sp_development_early_stage` cubre la planificación de proyectos en
32 etapas tempranas, con énfasis en involucrar a la comunidad de desarrollo
42 su revisión. Para ser tomados en serio por la comunidad de desarrollo,
48 parches; el trabajo está lejos de terminar en ese momento. Trabajar con
50 ofrece varios consejos sobre cómo evitar problemas en esta importante
52 terminado cuando un parche se fusiona en mainline.
65 1000 colaboradores en cada versión, en uno de los proyectos de software
66 libre más grandes y activos que existen. Desde sus humildes comienzos en
[all …]
|
| D | maintainer-kvm-x86.rst | 15 principiantes en algún momento. Mientras haga un esfuerzo honesto por
27 KVM x86 se encuentra actualmente en un período de transición de ser parte
33 Por lo general, las correcciones para el ciclo en curso se aplican
35 para el siguiente ciclo se dirige a través del árbol de KVM x86. En el
40 Tenga en cuenta que se espera que este periodo de transición dure bastante
41 tiempo, es decir, que será el statu quo en un futuro previsible.
45 El árbol de KVM x86 está organizado en múltiples ramas por temas. El
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
53 Todas las ramas temáticas, excepto ``next`` y ``fixes``, se agrupan en
[all …]
|
| D | howto.rst | 8 Cómo participar en el desarrollo del kernel de Linux
12 sobre cómo convertirse en desarrollador del kernel de Linux y explica cómo
13 trabajar con el y en su desarrollo. El documento no tratará ningún aspecto
17 Si algo en este documento quedara obsoleto, envíe parches al maintainer de
18 este archivo, que se encuentra en la parte superior del documento.
22 ¿De modo que quiere descubrir como convertirse en un/a desarrollador/a del
24 Linux para este dispositivo." El objetivo de este documento en enseñarle
28 de la forma en que lo hace.
30 El kernel esta principalmente escrito en C, con algunas partes que son
31 dependientes de la arquitectura en ensamblador. Un buen conocimiento de C
[all …]
|
| D | submitting-patches.rst | 8 Envío de parches: la guía esencial para incluir su código en el kernel
12 el proceso puede en ocasiones resultar desalentador si no se está
17 Este documento contiene una gran cantidad de sugerencias en un formato
28 usarlo, le hará la vida como desarrollador del kernel y en general mucho
44 Tenga en cuenta, sin embargo, que es posible que no desee desarrollar con
48 en el archivo MAINTAINERS para encontrar dicho árbol, o simplemente
65 código, describa el impacto que cree pueda tener en los usuarios. Tenga en
74 Cuantifique optimizaciones y beneficios/perdidas. Si asegura mejoras en
84 al respecto en detalles técnicos. Es importante describir el cambio en
88 El maintainer le agradecerá que escriba la descripción de su parche en un
[all …]
|
| D | deprecated.rst | 12 En un mundo perfecto, sería posible convertir todas las instancias de
13 alguna API obsoleta en una nueva API y quitar la API anterior en un
17 han de ir creándose en el kernel, mientras que las antiguas se quitan,
21 obsoletos son propuestos para incluir en el kernel.
30 que usar `__deprecated` es sencillo para anotar una API obsoleta en
33 desanimar a otros a usarla en el futuro.
37 Use WARN() y WARN_ON() en su lugar, y gestione las condiciones de error
42 "¿en qué orden se necesitan liberar los locks? ¿Se han restaurado sus
51 en situaciones que se "esperan no sean alcanzables". Si se quiere
55 ejecutándose en presencia del condiciones "no alcanzables". (Por ejemplo,
[all …]
|
| D | coding-style.rst | 8 Estilo en el código del kernel Linux
11 Este es un breve documento que describe el estilo preferido en el código
17 En primer lugar, sugeriría imprimir una copia de los estándares de código
33 buscando en su pantalla durante 20 horas seguidas, le resultará mucho más
37 el código se mueva demasiado a la derecha y dificulta la lectura en una
39 necesita más de 3 niveles de sangría, está en apuros de todos modos y
42 En resumen, las sangrías de 8 caracteres facilitan la lectura y tienen la
46 La forma preferida de facilitar múltiples niveles de sangría en una
48 ``case`` subordinadas en la misma columna, en lugar de hacer ``doble
49 sangría`` (``double-indenting``) en etiquetas ``case``. Por ejemplo:
[all …]
|
| D | researcher-guidelines.rst | 11 en su producción, otros subproductos de su desarrollo. Linux se
13 aspectos de Linux son impulsados por investigación en una forma u otra.
19 de Linux para mejorar a partir de ella. En cualquier caso, se recomienda
28 en general, ética en la tecnología y la investigación de las comunidades
29 de desarrolladores en particular, ver:
32 * `Historia de la Ética en la Investigación <https://www.unlv.edu/research/ORI-HSR/history-ethics>`_
34 * `Perspectivas de Desarrolladores e Investigadores sobre la Ética de los Experimentos en Proyectos…
37 el proyecto están participando en buena fe para mejorar Linux. La
43 La investigación pasiva que se basa completamente en fuentes disponibles
44 públicamente, incluidas las publicaciones en listas de correo públicas y
[all …]
|
| D | adding-syscalls.rst | 12 al kernel Linux, más allá de la presentación y consejos normales en
20 alguna alternativa es adecuada en su lugar. Aunque las llamadas al sistema
28 funcionalidad en un módulo del kernel en vez de requerir que sea
41 - Si sólo está exponiendo información del runtime, un nuevo nodo en sysfs
45 siempre el caso (e.g. en un ambiente namespaced/sandboxed/chrooted).
70 explícitamente el interface en las listas de correo del kernel, y es
93 argumentos, es preferible encapsular la mayoría de los argumentos en una
96 tamaño en la estructura::
107 entonces permite versiones no coincidentes en ambos sentidos:
118 Revise :manpage:`perf_event_open(2)` y la función ``perf_copy_attr()`` (en
[all …]
|
| D | handling-regressions.rst | 11 regla del desarrollo del kernel de Linux" y que implica en la práctica para
24 * Cuando se reciba un correo que no incluyó a la lista, inclúyalo en la
26 lista en CCed.
28 * Mande o redirija cualquier informe originado en los gestores de bugs
36 respuesta (con la lista de regresiones en CC) que contenga un párrafo
51 del incidente, como se indica en el documento:
57 deberían ser integradas en menos de dos semanas, pero algunas pueden
58 resolverse en dos o tres días.
60 Detalles importantes para desarrolladores en la regresiones de kernel de Linux
63 Puntos básicos importantes más en detalle
[all …]
|
| D | email-clients.rst | 14 A día de hoy, la mayoría de los desarrolladores usan ``git send-email`` en
16 para esto es bastante buena. En la recepción del correo, los maintainers
19 Si es usted nuevo en ``git`` entonces envíese su primer parche. Guárdelo
28 preferiblemente como texto en línea en el cuerpo del correo electrónico.
35 También se recomienda encarecidamente que utilice texto sin formato en el
55 estar en codificación ASCII o UTF-8 únicamente. Si configura su cliente de
64 parches, porque las tabulaciones se convierten en espacios. Utilizar
68 No utilice firmas PGP/GPG en el correo que contiene parches.
85 - TUI = text-based user interface (interfaz de usuario basada en texto)
93 En la sección :menuselection:`Sending Preferences`:
[all …]
|
| D | management-style.rst | 31 En primer lugar, sugeriría comprar “Seven Habits of Highly Effective
46 decisiones en importante. Cuanto más grande y dolorosa sea la decisión,
48 pero en realidad no es cierto.
50 El nombre del partido es **evitar** tener que tomar una decisión. En
52 que decidas sobre esto”, estas en problemas como gerente. Es mejor que
59 diferente. Es decir, que estas en el trabajo equivocado y que **ellos**
60 deberían gestionando tu brillantez en su lugar).
66 y dolorosas en cosas pequeñas a los que a nadie realmente le importa.
79 Por lo tanto, la llave para evitar las grandes decisiones se convierte en
99 nos gusta mantener las apariencias, y salir en público a decir que te
[all …]
|
| D | contribution-maturity-model.rst | 17 en el reclutamiento de mantenedores del kernel, así como la sucesión de
21 trabajo, para que puedan convertirse en lideres respetados y finalmente,
22 en mantenedores del kernel. Para apoyar una fuente solida de talento, se
38 y los desarrolladores en todos los niveles de antigüedad. En el espíritu
54 o en su propio tiempo.
64 considerarán en la promoción y las revisiones de rendimiento.
76 considerarán en la promoción y las revisiones de rendimiento.
89 del kernel en la organización.
90 * El intervalo de tiempo entre los kernels utilizados en los servidores
92 upstream en el que se basa el kernel interno.
[all …]
|
| D | submit-checklist.rst | 15 Todo esto está más allá de la documentación que se proporciona en
17 y en otros lugares con respecto al envío de parches del kernel de Linux.
38 3) Se compila en varias arquitecturas de CPU mediante herramientas de
44 5) Verifique su parche para el estilo general según se detalla en
49 en su parche.
53 criterios de excepción documentados en
69 cualquier función que use más de 512 bytes en la pila es
84 13) Ha sido probado en tiempo de compilación y ejecución con y sin
90 15) Todas las nuevas entradas de ``/proc`` están documentadas en
94 en ``Documentation/admin-guide/kernel-parameters.rst``.
[all …]
|
| D | security-bugs.rst | 10 Los desarrolladores del kernel de Linux se toman la seguridad muy en
20 electrónico en <security@kernel.org>. Esta es una lista privada de
30 procedimiento descrito en 'Documentation/admin-guide/reporting-issues.rst'
35 Por favor, envíe correos electrónicos en texto plano sin archivos
37 citada en contexto sobre un tema complejo si todos los detalles están
38 ocultos en archivos adjuntos. Piense en ello como un
41 de reproducción, y sígalo con una solución propuesta, todo en texto plano.
63 junto con la solución o en cualquier otro canal de divulgación sin el
68 En otras palabras, nuestro único interés es solucionar los errores. Toda
71 que se haya levantado el embargo, en perpetuidad.
[all …]
|
| D | code-of-conduct.rst | 15 a hacer de la participación en nuestra comunidad una experiencia libre de
35 * Centrarse en lo que sea mejor no sólo para nosotros como individuos, sino
36 para la comunidad en general
45 * El acoso en público o privado
50 inapropiadas en un entorno profesional
58 apropiadas y correctivas de forma justa en respuesta a cualquier
71 espacios públicos donde un individuo esté en representación del proyecto o
74 presentaciones con personas designadas en eventos en línea o no.
84 Detalles de políticas y aplicación en particular, serán incluidos por
91 1.4, disponible en https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
|
| D | embargoed-hardware-issues.rst | 13 Los problemas de hardware que resultan en problemas de seguridad son una
35 en el kernel de Linux no son manejados por este equipo y el "reportero"
37 del kernel de Linux (:doc:`errores de seguridad <security-bugs>`) en su
40 El equipo puede contactar por correo electrónico en
48 certificado de S/MIME de la lista están disponibles en las siguientes
71 Las listas de correo encriptadas que se utilizan en nuestro proceso están
72 alojados en la infraestructura de IT de la Fundación Linux. Al proporcionar
89 delicada de tales problemas y ofrece un Memorando de Entendimiento en su
101 seguridad del hardware en el pasado y tiene los mecanismos necesarios para
110 (expertos en dominio) que formarán el equipo de respuesta inicial para un
[all …]
|
| /Documentation/translations/sp_SP/scheduler/ |
| D | sched-eevdf.rst | 12 First", fue presentado por primera vez en una publicación científica en
13 1995 [1]. El kernel de Linux comenzó a transicionar hacia EEVPF en la
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
16 Zijlstra en 2023 [2-4]. Más información relativa a CFS puede encontrarse
17 en Documentation/scheduler/sched-design-CFS.rst.
24 de ejecución en la CPU. De esta manera, una tarea con un "retraso"
36 en tareas que estén en un estado durmiente; pero en el momento en el que
37 se escribe este texto EEVDF usa un mecanismo de "decaimiento" basado en el
40 reajustar su retraso negativo: cuando una tarea duerme, esta permanece en
[all …]
|
| D | sched-design-CFS.rst | 15 CFS viene de las siglas en inglés de "Gestor de tareas totalmente justo"
17 implementado por Ingo Molnar e integrado en Linux 2.6.23. Es el sustituto
18 del previo gestor de tareas SCHED_OTHER. Hoy en día se está abriendo camino
19 para el gestor de tareas EEVDF, cuya documentación se puede ver en
22 El 80% del diseño de CFS puede ser resumido en una única frase: CFS
28 velocidad, en paralelo, y cada una a 1/n velocidad. Por ejemplo, si hay dos
30 como si se ejecutaran en paralelo.
32 En hardware real, se puede ejecutar una única tarea a la vez, así que
35 de ejecución podría empezar en la CPU ideal multi-tarea descrita anteriormente.
36 En la práctica, el tiempo de ejecución virtual de una tarea es el
[all …]
|
| /Documentation/devicetree/bindings/iio/frequency/ |
| D | adi,adrf6780.yaml | 16 https://www.analog.com/en/products/adrf6780.html
41 adi,vga-buff-en:
47 adi,lo-buff-en:
53 adi,if-mode-en:
59 adi,iq-mode-en:
65 adi,lo-x2-en:
72 adi,lo-ppf-en:
79 adi,lo-en:
85 adi,uc-bias-en:
97 adi,vdet-out-en:
[all …]
|
| /Documentation/hwmon/ |
| D | max6697.rst | 10 Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6581.pdf
16 Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6602.pdf
22 Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6622.pdf
28 Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6636.pdf
34 Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6689.pdf
40 Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6693.pdf
46 Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6694.pdf
52 Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6697.pdf
58 Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6698.pdf
64 Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6699.pdf
|
| /Documentation/devicetree/bindings/iio/adc/ |
| D | adi,ad7380.yaml | 14 * https://www.analog.com/en/products/ad7380.html
15 * https://www.analog.com/en/products/ad7381.html
16 * https://www.analog.com/en/products/ad7383.html
17 * https://www.analog.com/en/products/ad7384.html
18 * https://www.analog.com/en/products/ad7386.html
19 * https://www.analog.com/en/products/ad7387.html
20 * https://www.analog.com/en/products/ad7388.html
21 * https://www.analog.com/en/products/ad7380-4.html
22 * https://www.analog.com/en/products/ad7381-4.html
23 * https://www.analog.com/en/products/ad7383-4.html
[all …]
|
| /Documentation/devicetree/bindings/leds/ |
| D | issi,is31fl319x.yaml | 14 Previously known as Si-En SN319{0,1,3,6,9}.
31 - si-en,sn3190
32 - si-en,sn3191
33 - si-en,sn3193
34 - si-en,sn3196
35 - si-en,sn3199
86 - si-en,sn3190
87 - si-en,sn3191
88 - si-en,sn3193
120 - si-en,sn3190
[all …]
|