| /linux-6.14.4/drivers/net/ethernet/mellanox/mlx5/core/ |
| D | Makefile | 25 mlx5_core-$(CONFIG_MLX5_CORE_EN) += en/rqt.o en/tir.o en/rss.o en/rx_res.o \
26 en/channels.o en_main.o en_common.o en_fs.o en_ethtool.o \
27 en_tx.o en_rx.o en_dim.o en_txrx.o en/xdp.o en_stats.o \
28 en_selftest.o en/port.o en/monitor_stats.o en/health.o \
29 en/reporter_tx.o en/reporter_rx.o en/params.o en/xsk/pool.o \
30 en/xsk/setup.o en/xsk/rx.o en/xsk/tx.o en/devlink.o en/ptp.o \
31 en/qos.o en/htb.o en/trap.o en/fs_tt_redirect.o en/selq.o \
39 mlx5_core-$(CONFIG_MLX5_CORE_EN_DCB) += en_dcbnl.o en/port_buffer.o
40 mlx5_core-$(CONFIG_PCI_HYPERV_INTERFACE) += en/hv_vhca_stats.o
42 en_rep.o en/rep/bond.o en/mod_hdr.o \
[all …]
|
| /linux-6.14.4/Documentation/translations/sp_SP/process/ |
| D | 4.Coding.rst | 13 kernel está en el código resultante. Es el código lo que será examinado por
14 otros desarrolladores y lo que será incluido (o no) en el árbol principal.
19 algunas de las maneras en que los desarrolladores del kernel pueden cometer
21 herramientas que pueden ayudar en dicha búsqueda.
30 estándar, descrito en la documentación del kernel en
32 las políticas descritas en ese archivo se tomaban como, en el mejor de los
34 código en el kernel que no cumple con las pautas de estilo de programación.
47 Ocasionalmente, el estilo de programación del kernel entrará en conflicto
48 con el estilo obligatorio de un empleador. En tales casos, el estilo del
50 Incluir código en el kernel significa renunciar a cierto grado de control
[all …]
|
| 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 | 7.AdvancedTopics.rst | 14 que desean convertirse en una parte regular del proceso de desarrollo del
25 del proyecto de desarrollo del kernel. En los tiempos actuales, existen
35 derecho propio. En su lugar, el enfoque aquí será cómo git encaja en el
36 proceso de desarrollo del kernel en particular. Los desarrolladores que
37 deseen ponerse al día con git encontrarán más información en:
43 y en varios tutoriales que se encuentran en la web.
49 de revisiones, hacer commits en el árbol, usar ramas, etcétera. También es
65 comenzando a aparecer en la red. Los desarrolladores establecidos pueden
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
[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 | 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 | 5.Posting.rst | 11 Tarde o temprano, llega el momento en que su trabajo esté listo para ser
13 en el kernel mainline. Como era de esperar, la comunidad de desarrollo del
15 utilizan en la publicación de parches; seguirlos hará la vida mucho más
18 información en los archivos.
30 trabajo en progreso, o incluso poner a disposición un árbol de git para
32 en cualquier momento.
35 una buena idea decirlo en la propia publicación. Además, mencione
39 ayudarlo a llevar el trabajo en la dirección correcta.
47 - Pruebe el código en la medida de lo posible. Utilice las herramientas
65 siempre compensa el esfuerzo en poco tiempo.
[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 | 3.Early-stage.rst | 8 Planificación en etapa inicial
16 ahorrar mucho más tiempo en adelante.
21 Como en cualquier proyecto de ingeniería, una mejora exitosa del kernel
22 comienza con una descripción clara del problema a resolver. En algunos
24 específico, por ejemplo. En otros, sin embargo, es tentador confundir el
28 trabajaban con audio en Linux buscaban una forma de ejecutar aplicaciones
29 sin interrupciones u otros artefactos causados por la latencia excesiva en
31 destinado a integrarse en el marco del Módulo de Seguridad de Linux (LSM,
32 por sus siglas en inglés); este módulo podía configurarse para dar acceso a
33 aplicaciones específicas al planificador en tiempo real. Este módulo fue
[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 | 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
19 Es raro un parche que sea tan bueno en su primera publicación que no haya
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
34 más fácil si tiene en cuenta algunas cosas:
39 código en él cinco o diez años después? Muchos de los cambios que se le
42 seguirá existiendo y en desarrollo dentro de una década.
56 del kernel a menudo esperan estar trabajando en el kernel dentro de
[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 …]
|
| /linux-6.14.4/Documentation/translations/sp_SP/scheduler/ |
| D | sched-bwc.rst | 14 para SCHED_NORMAL. El caso de SCHED_RT se trata en Documentation/scheduler/sched-rt-group.rst
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
25 ha sido asignada cualquier petición adicional de cuota resultará en esos hilos
33 transfiere a los "silos" de las cpu-locales en base a la demanda. La
34 cantidad transferida en cada una de esas actualizaciones es ajustable y
40 Esta característica toma prestado tiempo ahora, que en un futuro tendrá que
52 límite de ejecución de la tarea, pero en el siguiente periodo de ejecución
54 tiempo de alcanzar la ejecución, cayendo así en un fallo no acotado.
[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 …]
|
| /linux-6.14.4/Documentation/translations/sp_SP/ |
| 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 …]
|
| 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 …]
|
| /linux-6.14.4/drivers/gpu/drm/amd/display/dc/gpio/dce60/ |
| D | hw_translate_dce60.c | 67 uint32_t *en) in offset_to_id() argument
75 *en = GPIO_GENERIC_A; in offset_to_id()
78 *en = GPIO_GENERIC_B; in offset_to_id()
81 *en = GPIO_GENERIC_C; in offset_to_id()
84 *en = GPIO_GENERIC_D; in offset_to_id()
87 *en = GPIO_GENERIC_E; in offset_to_id()
90 *en = GPIO_GENERIC_F; in offset_to_id()
93 *en = GPIO_GENERIC_G; in offset_to_id()
105 *en = GPIO_HPD_1; in offset_to_id()
108 *en = GPIO_HPD_2; in offset_to_id()
[all …]
|
| /linux-6.14.4/drivers/gpu/drm/amd/display/dc/gpio/dce80/ |
| D | hw_translate_dce80.c | 67 uint32_t *en) in offset_to_id() argument
75 *en = GPIO_GENERIC_A; in offset_to_id()
78 *en = GPIO_GENERIC_B; in offset_to_id()
81 *en = GPIO_GENERIC_C; in offset_to_id()
84 *en = GPIO_GENERIC_D; in offset_to_id()
87 *en = GPIO_GENERIC_E; in offset_to_id()
90 *en = GPIO_GENERIC_F; in offset_to_id()
93 *en = GPIO_GENERIC_G; in offset_to_id()
105 *en = GPIO_HPD_1; in offset_to_id()
108 *en = GPIO_HPD_2; in offset_to_id()
[all …]
|
| /linux-6.14.4/drivers/gpu/drm/amd/display/dc/gpio/dce110/ |
| D | hw_translate_dce110.c | 43 uint32_t *en) in offset_to_id() argument
51 *en = GPIO_GENERIC_A; in offset_to_id()
54 *en = GPIO_GENERIC_B; in offset_to_id()
57 *en = GPIO_GENERIC_C; in offset_to_id()
60 *en = GPIO_GENERIC_D; in offset_to_id()
63 *en = GPIO_GENERIC_E; in offset_to_id()
66 *en = GPIO_GENERIC_F; in offset_to_id()
69 *en = GPIO_GENERIC_G; in offset_to_id()
81 *en = GPIO_HPD_1; in offset_to_id()
84 *en = GPIO_HPD_2; in offset_to_id()
[all …]
|
| /linux-6.14.4/fs/f2fs/ |
| D | extent_cache.c | 138 struct extent_node *en) in __try_update_largest_extent() argument
142 if (en->ei.len <= et->largest.len) in __try_update_largest_extent()
145 et->largest = en->ei; in __try_update_largest_extent()
186 struct extent_node *en; in __lookup_extent_node() local
195 en = rb_entry(node, struct extent_node, rb_node); in __lookup_extent_node()
197 if (fofs < en->ei.fofs) in __lookup_extent_node()
199 else if (fofs >= en->ei.fofs + en->ei.len) in __lookup_extent_node()
202 return en; in __lookup_extent_node()
227 struct extent_node *en = cached_en; in __lookup_extent_node_ret() local
237 if (en && en->ei.fofs <= fofs && en->ei.fofs + en->ei.len > fofs) in __lookup_extent_node_ret()
[all …]
|
| /linux-6.14.4/drivers/gpu/drm/amd/display/dc/gpio/dcn10/ |
| D | hw_translate_dcn10.c | 65 uint32_t *en) in offset_to_id() argument
73 *en = GPIO_GENERIC_A; in offset_to_id()
76 *en = GPIO_GENERIC_B; in offset_to_id()
79 *en = GPIO_GENERIC_C; in offset_to_id()
82 *en = GPIO_GENERIC_D; in offset_to_id()
85 *en = GPIO_GENERIC_E; in offset_to_id()
88 *en = GPIO_GENERIC_F; in offset_to_id()
91 *en = GPIO_GENERIC_G; in offset_to_id()
103 *en = GPIO_HPD_1; in offset_to_id()
106 *en = GPIO_HPD_2; in offset_to_id()
[all …]
|
| /linux-6.14.4/drivers/gpu/drm/amd/display/dc/gpio/dce120/ |
| D | hw_translate_dce120.c | 65 uint32_t *en) in offset_to_id() argument
73 *en = GPIO_GENERIC_A; in offset_to_id()
76 *en = GPIO_GENERIC_B; in offset_to_id()
79 *en = GPIO_GENERIC_C; in offset_to_id()
82 *en = GPIO_GENERIC_D; in offset_to_id()
85 *en = GPIO_GENERIC_E; in offset_to_id()
88 *en = GPIO_GENERIC_F; in offset_to_id()
91 *en = GPIO_GENERIC_G; in offset_to_id()
103 *en = GPIO_HPD_1; in offset_to_id()
106 *en = GPIO_HPD_2; in offset_to_id()
[all …]
|