| /linux-6.14.4/Documentation/translations/sp_SP/process/ |
| D | embargoed-hardware-issues.rst | 7 Problemas de hardware embargados
13 Los problemas de hardware que resultan en problemas de seguridad son una
14 categoría diferente de errores de seguridad que los errores de software
15 puro que solo afectan al kernel de Linux.
17 Los problemas de hardware como Meltdown, Spectre, L1TF, etc. deben
18 tratarse de manera diferente porque usualmente afectan a todos los
20 vendedores diferentes de OS, distribuciones, vendedores de hardware y
21 otras partes. Para algunos de los problemas, las mitigaciones de software
22 pueden depender de actualizaciones de microcódigo o firmware, los cuales
30 El equipo de seguridad de hardware del kernel de Linux es separado del
[all …]
|
| D | 4.Coding.rst | 11 Si bien hay mucho que decir a favor de un proceso de diseño sólido y
12 orientado a la comunidad, la prueba de cualquier proyecto de desarrollo del
15 Por lo tanto, es la calidad de este código lo que determinará el éxito
18 Esta sección examinará el proceso de programación. Comenzaremos observando
19 algunas de las maneras en que los desarrolladores del kernel pueden cometer
26 Estilo de programación
29 El kernel ha tenido durante mucho tiempo un estilo de programación
31 `Documentation/process/coding-style.rst`. Durante gran parte de ese tiempo,
32 las políticas descritas en ese archivo se tomaban como, en el mejor de los
33 casos, orientativas. Como resultado, hay una cantidad considerable de
[all …]
|
| D | 2.Process.rst | 8 Cómo funciona el proceso de desarrollo
11 El desarrollo del kernel de Linux a principios de la década de 1990 fue
12 un asunto relajado, con un número relativamente pequeño de usuarios y
13 desarrolladores involucrados. Con una base de usuarios en los millones y
14 alrededor de 2,000 desarrolladores involucrados durante un año, el kernel
16 problemas. Se requiere una comprensión solida de cómo funciona el proceso
22 Los desarrolladores del kernel utilizan un proceso de lanzamiento basado
23 en el tiempo de manera flexible, con uno nuevo lanzamiento principal del
24 kernel ocurriendo cada dos o tres meses. El historial reciente de
38 puede contener alrededor de 13,000 conjuntos de cambios incluyendo en
[all …]
|
| D | 1.Intro.rst | 14 El resto de esta sección cubre el alcance del proceso de desarrollo del
15 kernel y los tipos de frustraciones que los desarrolladores y sus
18 incluyendo la disponibilidad automática para los usuarios, el apoyo de la
19 comunidad en muchas formas, y la capacidad de influir en la dirección del
20 desarrollo del kernel. El código contribuido al kernel de Linux debe
23 :ref:`sp_development_process` introduce el proceso de desarrollo, el ciclo
24 de lanzamiento del kernel y la mecánica de la "ventana de combinación"
26 la revisión y, el ciclo de fusión. Hay algunas discusiones sobre
27 herramientas y listas de correo. Se anima a los desarrolladores que deseen
31 :ref:`sp_development_early_stage` cubre la planificación de proyectos en
[all …]
|
| D | maintainer-kvm-x86.rst | 11 KVM se esfuerza por ser una comunidad acogedora; las contribuciones de los
13 se sienta intimidado por la extensión de este documento y las numerosas
16 seguir las directrices de KVM x86, sea receptivo a los comentarios, y
17 aprenda de los errores que cometa, será recibido con los brazos abiertos,
27 KVM x86 se encuentra actualmente en un período de transición de ser parte
28 del árbol principal de KVM, a ser "sólo otra rama de KVM". Como tal, KVM
29 x86 está dividido entre el árbol principal de KVM,
30 ``git.kernel.org/pub/scm/virt/kvm/kvm.git``, y un árbol específico de KVM
34 directamente al árbol principal de KVM, mientras que todo el desarrollo
35 para el siguiente ciclo se dirige a través del árbol de KVM x86. En el
[all …]
|
| D | howto.rst | 8 Cómo participar en el desarrollo del kernel de Linux
11 Este documento es el principal punto de partida. Contiene instrucciones
12 sobre cómo convertirse en desarrollador del kernel de Linux y explica cómo
17 Si algo en este documento quedara obsoleto, envíe parches al maintainer de
22 ¿De modo que quiere descubrir como convertirse en un/a desarrollador/a del
23 kernel de Linux? Tal vez su jefe le haya dicho, "Escriba un driver de
24 Linux para este dispositivo." El objetivo de este documento en enseñarle
26 que debe pasar, y con indicaciones de como trabajar con la comunidad.
27 También trata de explicar las razones por las cuales la comunidad trabaja
28 de la forma en que lo hace.
[all …]
|
| D | coding-style.rst | 12 del kernel Linux. El estilo de código es muy personal y no **forzaré** mi
13 puntos de vista sobre nadie, pero esto vale para todo lo que tengo que
14 mantener, y preferiría que para la mayoría de otras cosas también. Por
17 En primer lugar, sugeriría imprimir una copia de los estándares de código
20 De todos modos, aquí va:
28 de 4 (¡o incluso 2!) caracteres de longitud, y eso es similar a tratar de
29 definir el valor de PI como 3.
31 Justificación: La idea detrás de la sangría es definir claramente dónde
32 comienza y termina un bloque de control. Especialmente, cuando ha estado
36 Bueno, algunas personas dirán que tener sangrías de 8 caracteres hace que
[all …]
|
| D | 6.Followthrough.rst | 12 sumado a sus propias habilidades de ingeniería, ha resultado en una serie
13 de parches perfectos. Uno de los mayores errores que incluso los
14 desarrolladores de kernel experimentados pueden cometer es concluir que su
20 espacio para la mejora. El proceso de desarrollo del kernel reconoce este
22 publicado. Y usted, como autor de ese código, se espera que trabaje con la
23 comunidad del kernel para asegurarse de que su código esté a la altura de
24 los estándares de calidad del kernel. No participar en este proceso es muy
25 probable que impida la inclusión de sus parches en la línea principal.
30 Un parche de cualquier importancia resultará en una serie de comentarios de
33 del proceso de desarrollo del kernel. Sin embargo, la vida puede ser mucho
[all …]
|
| D | contribution-maturity-model.rst | 8 Modelo de Madurez de Contribución al Kernel de Linux
15 Como parte de la cumbre de mantenedores del kernel de Linux 2021, hubo
17 en el reclutamiento de mantenedores del kernel, así como la sucesión de
18 los mantenedores. Algunas de las conclusiones de esa discusión incluyeron
19 que las empresas que forman parte de la comunidad del kernel de Linux
20 necesitan permitir que los ingenieros sean mantenedores como parte de su
22 en mantenedores del kernel. Para apoyar una fuente solida de talento, se
24 upstream, como revisar los parches de otras personas, reestructurar la
27 Con ese fin, Technical Advisory Board (TAB) de la Fundación Linux propone
28 este Modelo de Madurez de Contribución al Kernel de Linux. Estas
[all …]
|
| D | submitting-patches.rst | 8 Envío de parches: la guía esencial para incluir su código en el kernel
13 familiarizado con "el sistema". Este texto es una colección de sugerencias
14 que pueden aumentar considerablemente las posibilidades de que se acepte su
17 Este documento contiene una gran cantidad de sugerencias en un formato
19 funciona el proceso de desarrollo del kernel, consulte
21 Documentation/process/submit-checklist.rst para obtener una lista de
22 elementos a verificar antes de enviar código. Para los parches de
23 "binding" del árbol de dispositivos, lea
31 Algunos subsistemas y árboles de mantenimiento cuentan con información
32 adicional sobre su flujo de trabajo y expectativas, consulte
[all …]
|
| D | adding-syscalls.rst | 12 al kernel Linux, más allá de la presentación y consejos normales en
21 son los puntos de interacción entre el userspace y el kernel más obvios y
26 podría tener más sentido crear un nuevo sistema de ficheros o
28 funcionalidad en un módulo del kernel en vez de requerir que sea
33 descriptor de archivo para el objeto relevante permite al userspace
47 interfaz (interface) de 'producción' para el userspace.
49 - Si la operación es específica a un archivo o descriptor de archivo
50 específico, entonces la opción de comando adicional :manpage:`fcntl(2)`
56 un descriptor de archivo).
70 explícitamente el interface en las listas de correo del kernel, y es
[all …]
|
| D | handling-regressions.rst | 7 Gestión de regresiones
11 regla del desarrollo del kernel de Linux" y que implica en la práctica para
14 desde el punto de vista de un usuario; si nunca ha leído ese texto, realice
15 al menos una lectura rápida del mismo antes de continuar.
20 #. Asegúrese de que los suscriptores a la lista `regression mailing list
22 son conocedores con rapidez de cualquier nuevo informe de regresión:
25 conversación de los correos, mandando un breve "Reply-all" con la
28 * Mande o redirija cualquier informe originado en los gestores de bugs
31 #. Haga que el bot del kernel de Linux "regzbot" realice el seguimiento del
36 respuesta (con la lista de regresiones en CC) que contenga un párrafo
[all …]
|
| D | 7.AdvancedTopics.rst | 11 Llegados a este punto, con suerte, tiene una idea de cómo funciona el
12 proceso de desarrollo. Sin embargo, ¡todavía hay más que aprender! Esta
14 que desean convertirse en una parte regular del proceso de desarrollo del
20 El uso del control de versiones distribuido para el kernel comenzó a
21 principios de 2002 cuando Linus comenzó a jugar con la aplicación
22 propietaria BitKeeper. Aunque BitKeeper fue controvertido, el enfoque de
23 la gestión de versiones de software que incorporó ciertamente no lo fue.
24 El control de versiones distribuido permitió una aceleración inmediata
25 del proyecto de desarrollo del kernel. En los tiempos actuales, existen
30 desarrollador, especialmente a medida que crece el volumen de esos
[all …]
|
| D | 3.Early-stage.rst | 11 Cuando uno se sienta a planear un proyecto de desarrollo del kernel Linux,
14 que conduce al éxito es mejor realizarlo antes de escribir la primera línea
15 de código. Dedicar tiempo a la planificación y comunicación temprana puede
21 Como en cualquier proyecto de ingeniería, una mejora exitosa del kernel
28 trabajaban con audio en Linux buscaban una forma de ejecutar aplicaciones
31 destinado a integrarse en el marco del Módulo de Seguridad de Linux (LSM,
34 implementado y enviado a la lista de correo del kernel de Linux, donde
37 Para los desarrolladores de audio, este módulo de seguridad era suficiente
40 diseñado para otorgar privilegios a procesos que de otro modo no los
43 del mecanismo de rlimit a corto plazo, y trabajo continuo para reducir la
[all …]
|
| D | 5.Posting.rst | 8 Publicación de parches
13 en el kernel mainline. Como era de esperar, la comunidad de desarrollo del
14 kernel ha desarrollado un conjunto de convenciones y procedimientos que se
15 utilizan en la publicación de parches; seguirlos hará la vida mucho más
25 Hay una tentación constante de evitar publicar parches antes de que
28 hay mucho que ganar al obtener comentarios de la comunidad antes de que
30 trabajo en progreso, o incluso poner a disposición un árbol de git para
38 medias, pero aquellos que lo hagan vendrán con la idea de que pueden
41 Antes de crear parches
44 Se deben hacer varias cosas antes de considerar enviar parches a la
[all …]
|
| D | deprecated.rst | 12 En un mundo perfecto, sería posible convertir todas las instancias de
14 único ciclo de desarrollo. Desafortunadamente, debido al tamaño del kernel,
15 la jerarquía de mantenimiento, y el tiempo, no siempre es posible hacer
16 estos cambios de una única vez. Esto significa que las nuevas instancias
17 han de ir creándose en el kernel, mientras que las antiguas se quitan,
18 haciendo que la cantidad de trabajo para limpiar las APIs crezca. Para
28 porque uno de los objetivos del kernel es que compile sin avisos, y
31 un archivo de cabecera, no es la solución completa. Dichos interfaces
37 Use WARN() y WARN_ON() en su lugar, y gestione las condiciones de error
38 "imposibles" tan elegantemente como se pueda. Mientras que la familia de
[all …]
|
| D | kernel-enforcement-statement.rst | 8 Aplicación de la licencia en el kernel Linux
12 se utiliza nuestro software y cómo se aplica la licencia de nuestro software.
13 El cumplimiento de las obligaciones de intercambio recíproco de GPL-2.0 son
14 fundamentales en el largo plazo para la sostenibilidad de nuestro software
17 Aunque existe el derecho de hacer valer un copyright distinto en las
18 contribuciones hechas a nuestra comunidad, compartimos el interés de
20 de una manera que beneficia a nuestra comunidad y no tenga un indeseado
21 impacto negativo en la salud y crecimiento de nuestro ecosistema de software.
22 Con el fin de disuadir la aplicación inútil de acciones, estamos de acuerdo
23 en que es en el mejor interés de nuestro desarrollo como comunidad asumir
[all …]
|
| D | email-clients.rst | 8 Información de clientes de correo electrónico para Linux
14 A día de hoy, la mayoría de los desarrolladores usan ``git send-email`` en
15 lugar de los clientes de correo electrónico normales. La página de manual
21 y luego revise el registro de cambios con ``git log``. Cuando eso funcione,
22 envíe el parche a la(s) lista(s) de correo apropiada(s).
27 Los parches para el kernel de Linux se envían por correo electrónico,
30 adjuntos deben tener tipo de contenido ``text/plain``. Sin embargo, los
32 partes del parche sea más difícil durante el proceso de revisión del
38 información sobre cómo configurar su cliente de correo electrónico
39 preferido, así como una lista de clientes de correo electrónico
[all …]
|
| D | security-bugs.rst | 7 Errores de seguridad
10 Los desarrolladores del kernel de Linux se toman la seguridad muy en
11 serio. Como tal, nos gustaría saber cuándo se encuentra un error de
13 Por favor, informe sobre los errores de seguridad al equipo de seguridad
14 del kernel de Linux.
19 El equipo de seguridad del kernel de Linux puede ser contactado por correo
20 electrónico en <[email protected]>. Esta es una lista privada de
21 oficiales de seguridad que ayudarán a verificar el informe del error y
24 el proceso. Es posible que el equipo de seguridad traiga ayuda adicional
25 de mantenedores del área para comprender y corregir la vulnerabilidad de
[all …]
|
| D | management-style.rst | 9 Estilo de gestión del kernel de Linux
12 Este es un documento breve que describe el estilo de gestión preferido (o
13 inventado, dependiendo de a quién le preguntes) para el kernel de Linux.
19 El estilo de gestión es muy personal y mucho más difícil de cuantificar
20 que reglas simples de estilo de codificación, por lo que este documento
25 Por cierto, cuando se hable de “gerente de kernel”, se refiere a las
26 personas lideres técnicas, no de las personas que hacen la gestión
27 tradicional dentro de las empresas. Si firmas pedidos de compra o tienes
28 alguna idea sobre el presupuesto de tu grupo, es casi seguro que no eres
29 un gerente de kernel. Estas sugerencias pueden o no aplicarse a usted.
[all …]
|
| /linux-6.14.4/Documentation/translations/sp_SP/scheduler/ |
| D | sched-design-CFS.rst | 9 Gestor de tareas CFS
15 CFS viene de las siglas en inglés de "Gestor de tareas totalmente justo"
16 ("Completely Fair Scheduler"), y es el nuevo gestor de tareas de escritorio
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
27 de potencia y que puede ejecutar cualquier tarea exactamente a la misma
29 tareas ejecutándose, entonces cada una usa un 50% de la potencia --- es decir,
33 se ha usado el concepto de "tiempo de ejecución virtual". El tiempo
34 de ejecución virtual de una tarea específica cuando la siguiente porción
[all …]
|
| D | sched-bwc.rst | 9 CFS con control de ancho de banda
13 Este documento únicamente trata el control de ancho de banda de CPUs
14 para SCHED_NORMAL. El caso de SCHED_RT se trata en Documentation/scheduler/sched-rt-group.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
20 cuota y un periodo. Dentro de un "periodo" (microsegundos), a un grupo
21 de tareas se le asigna hasta su "cuota" de tiempo de uso de CPU en
22 microsegundos. Esa cuota es asignada para cada CPU en colas de ejecución
23 en porciones de tiempo de ejecución en la CPU según los hilos de ejecución
[all …]
|
| /linux-6.14.4/Documentation/translations/sp_SP/ |
| D | memory-barriers.txt | 13 BARRERAS DE MEMORIA EN EL KERNEL LINUX
22 Nota: Si tiene alguna duda sobre la exactitud del contenido de esta
31 de brevedad) y sin querer (por ser humanos) incompleta. Este documento
32 pretende ser una guía para usar las diversas barreras de memoria
34 pregunte. Algunas dudas pueden ser resueltas refiriéndose al modelo de
35 consistencia de memoria formal y documentación en tools/memory-model/. Sin
36 embargo, incluso este modelo debe ser visto como la opinión colectiva de
37 sus maintainers en lugar de que como un oráculo infalible.
39 De nuevo, este documento no es una especificación de lo que Linux espera
42 El propósito de este documento es doble:
[all …]
|
| /linux-6.14.4/drivers/net/ethernet/dec/tulip/ |
| D | de2104x.c | 327 static void de_tx (struct de_private *de);
328 static void de_clean_rings (struct de_private *de);
329 static void de_media_interrupt (struct de_private *de, u32 status);
332 static unsigned int de_ok_to_advertise (struct de_private *de, u32 new_media);
366 #define dr32(reg) ioread32(de->regs + (reg))
367 #define dw32(reg, val) iowrite32((val), de->regs + (reg))
370 static void de_rx_err_acct (struct de_private *de, unsigned rx_tail, in de_rx_err_acct() argument
373 netif_dbg(de, rx_err, de->dev, in de_rx_err_acct()
380 netif_warn(de, rx_err, de->dev, in de_rx_err_acct()
383 de->dev->stats.rx_length_errors++; in de_rx_err_acct()
[all …]
|
| /linux-6.14.4/fs/hpfs/ |
| D | dnode.c | 14 struct hpfs_dirent *de; in get_pos() local
17 for (de = dnode_first_de(d); de < de_end; de = de_next_de(de)) { in get_pos()
18 if (de == fde) return ((loff_t) le32_to_cpu(d->self) << 4) | (loff_t)i; in get_pos()
122 struct hpfs_dirent *de, *de_end, *dee = NULL, *deee = NULL; in dnode_pre_last_de() local
124 for (de = dnode_first_de(d); de < de_end; de = de_next_de(de)) { in dnode_pre_last_de()
125 deee = dee; dee = de; in dnode_pre_last_de()
132 struct hpfs_dirent *de, *de_end, *dee = NULL; in dnode_last_de() local
134 for (de = dnode_first_de(d); de < de_end; de = de_next_de(de)) { in dnode_last_de()
135 dee = de; in dnode_last_de()
142 struct hpfs_dirent *de; in set_last_pointer() local
[all …]
|