Home
last modified time | relevance | path

Searched +full:si +full:- +full:en (Results 1 – 25 of 81) sorted by relevance

1234

/linux/Documentation/translations/sp_SP/process/
H A Dmaintainer-kvm-x86.rst1 .. include:: ../disclaimer-sp.rst
3 :Original: Documentation/process/maintainer-kvm-x86.rst
10 --------
15 principiantes en algún momento. Mientras haga un esfuerzo honesto por
21 -----
26 -------
27 KVM x86 se encuentra actualmente en un período de transición de ser parte
31 x86, ``github.com/kvm-x86/linux.git``.
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
[all …]
H A Dsubmitting-patches.rst1 .. include:: ../disclaimer-sp.rst
3 :Original: :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
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
20 Documentation/process/development-process.rst. Además, lea
21 Documentation/process/submit-checklist.rst para obtener una lista de
24 Documentation/devicetree/bindings/submitting-patches.rst.
27 Si no está familiarizado con ``git``, le recomendamos que aprenda a
28 usarlo, le hará la vida como desarrollador del kernel y en general mucho
[all …]
H A Dadding-syscalls.rst1 .. include:: ../disclaimer-sp.rst
3 :Original: :ref:`Documentation/process/adding-syscalls.rst <addsyscalls>`
12 al kernel Linux, más allá de la presentación y consejos normales en
13 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` que
17 -----------------------------------
19 La primera cosa a considerar cuando se agrega una llamada al sistema es si
20 alguna alternativa es adecuada en su lugar. Aunque las llamadas al sistema
22 tradicionales, existen otras posibilidades -- elija la que mejor se adecúe
25 - Si se puede hacer que la operación se parezca a un objeto filesystem,
28 funcionalidad en un módulo del kernel en vez de requerir que sea
[all …]
H A Dhandling-regressions.rst1 .. include:: ../disclaimer-sp.rst
10 *No causamos regresiones* -- este documento describe la que es la "primera
11 regla del desarrollo del kernel de Linux" y que implica en la práctica para
13 Documentation/admin-guide/reporting-regressions.rst, que cubre el tema
14 desde el punto de vista de un usuario; si nunca ha leído ese texto, realice
24 * Cuando se reciba un correo que no incluyó a la lista, inclúyalo en la
25 conversación de los correos, mandando un breve "Reply-all" con la
26 lista en CCed.
28 * Mande o redirija cualquier informe originado en los gestores de bugs
34 * Para reportes enviados por correo, verificar si contiene alguna línea
[all …]
H A Dcoding-style.rst1 .. include:: ../disclaimer-sp.rst
3 :Original: :ref:`Documentation/process/coding-style.rst <submittingpatches>`
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
24 -----------
33 buscando en su pantalla durante 20 horas seguidas, le resultará mucho más
34 fácil ver cómo funciona la sangría si tiene sangrías grandes.
37 el código se mueva demasiado a la derecha y dificulta la lectura en una
38 pantalla de terminal de 80 caracteres. La respuesta a eso es que si
[all …]
H A Dmanagement-style.rst1 .. include:: ../disclaimer-sp.rst
3 :Original: Documentation/process/management-style.rst
15 :ref:`translations/sp_SP/process/coding-style.rst <sp_codingstyle>` hasta
27 tradicional dentro de las empresas. Si firmas pedidos de compra o tienes
31 En primer lugar, sugeriría comprar “Seven Habits of Highly Effective
43 -------------
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
51 particular, si alguien te dice “elige (a) o (b), realmente necesitamos
[all …]
H A Dsecurity-bugs.rst1 .. SPDX-License-Identifier: GPL-2.0
2 .. include:: ../disclaimer-sp.rst
4 :Original: Documentation/process/security-bugs.rst
10 Los desarrolladores del kernel de Linux se toman la seguridad muy en
17 --------
20 electrónico en <security@kernel.org>. Esta es una lista privada de
22 desarrollarán y publicarán una corrección. Si ya tiene una corrección, por
30 procedimiento descrito en 'Documentation/admin-guide/reporting-issues.rst'
31 si no tiene claro que información es útil. Cualquier código de explotación
35 Por favor, envíe correos electrónicos en texto plano sin archivos
[all …]
H A Ddeprecated.rst1 .. include:: ../disclaimer-sp.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.
24 ------------
30 que usar `__deprecated` es sencillo para anotar una API obsoleta en
33 desanimar a otros a usarla en el futuro.
36 ----------------
37 Use WARN() y WARN_ON() en su lugar, y gestione las condiciones de error
[all …]
H A Demail-clients.rst1 .. include:: ../disclaimer-sp.rst
3 :Original: :ref:`Documentation/process/email-clients.rst <email_clients>`
12 ---
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
25 ----------------------
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
40 recomendados si aún no tiene una preferencia.
[all …]
H A Dembargoed-hardware-issues.rst1 .. SPDX-License-Identifier: GPL-2.0
2 .. include:: ../disclaimer-sp.rst
4 :Original: Documentation/process/embargoed-hardware-issues.rst
11 -------
13 Los problemas de hardware que resultan en problemas de seguridad son una
28 --------
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
41 <hardware-security@kernel.org>. Esta es una lista privada de oficiales de
[all …]
H A Dhowto.rst1 .. include:: ../disclaimer-sp.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.
21 ------------
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.
[all …]
H A Dresearcher-guidelines.rst1 .. SPDX-License-Identifier: GPL-2.0
3 :Original: :ref:`Documentation/process/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.
15 La comunidad agradece mucho si los investigadores pueden compartir
17 especialmente si tal investigación involucra seguridad. Involucrarse
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>`_
[all …]
H A Dsubmit-checklist.rst1 .. include:: ../disclaimer-sp.rst
3 :Original: Documentation/process/submit-checklist.rst
11 Aquí hay algunas cosas básicas que los desarrolladores deben hacer si
15 Todo esto está más allá de la documentación que se proporciona en
16 :ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`
17 y en otros lugares con respecto al envío de parches del kernel de Linux.
19 1) Si utiliza una funcionalidad, #include el archivo que define/declara
38 3) Se compila en varias arquitecturas de CPU mediante herramientas de
42 por que tiende a usar ``unsigned long`` para cantidades de 64-bits.
44 5) Verifique su parche para el estilo general según se detalla en
[all …]
H A D2.Process.rst1 .. include:: ../disclaimer-sp.rst
13 desarrolladores involucrados. Con una base de usuarios en los millones y
20 -------------------
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
62 5.6-rc1. El lanzamiento -rc1 señala que el tiempo para fusionar nuevas
[all …]
H A D1.Intro.rst1 .. include:: ../disclaimer-sp.rst
12 -----------------
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.
[all …]
H A Dkernel-enforcement-statement.rst1 .. include:: ../disclaimer-sp.rst
3 :Original: :ref:`Documentation/process/kernel-enforcement-statement.rst <process_statement_kernel>`
8 Aplicación de la licencia en el kernel Linux
11 Como desarrolladores del kernel Linux, tenemos un gran interés en cómo se
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
21 impacto negativo en la salud y crecimiento de nuestro ecosistema de software.
23 en que es en el mejor interés de nuestro desarrollo como comunidad asumir
24 el siguiente compromiso con los usuarios del kernel Linux, en nombre
[all …]
H A Dkernel-docs.rst1 .. include:: ../disclaimer-sp.rst
3 :Original: :ref:`Documentation/process/kernel-docs.rst <kernel_docs>`
11 La necesidad de un documento como este se hizo evidente en la lista de
12 correo de linux-kernel cuando las mismas preguntas, solicitando sugerencias
25 POR FAVOR, si conoce algún documento que no figura aquí, o si escribe un
33 documento en cuestión.
37 Los documentos de cada sección en este documento están ordenados por su
41 Documentos en el árbol del kernel Linux
42 -----------------------------------------
53 (incluido este documento en sí) se han trasladado allí, y podrían
[all …]
/linux/Documentation/devicetree/bindings/leds/
H A Dissi,is31fl319x.yaml1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Vincent Knecht <vincent.knecht@mailoo.org>
14 Previously known as Si-En SN319{0,1,3,6,9}.
26 - issi,is31fl3190
27 - issi,is31fl3191
28 - issi,is31fl3193
29 - issi,is31fl3196
30 - issi,is31fl3199
[all …]
H A Dleds-is31fl32xx.txt1 Binding for ISSI IS31FL32xx and Si-En SN32xx LED Drivers
4 constant-current channels, each with independent 256-level PWM control.
5 Each LED is represented as a sub-node of the device.
8 - compatible: one of
13 si-en,sn3218
14 si-en,sn3216
15 - reg: I2C slave address
16 - address-cells : must be 1
17 - size-cells : must be 0
19 LED sub-node properties:
[all …]
/linux/Documentation/translations/sp_SP/
H A Dmemory-barriers.txt2 This is a version of Documentation/memory-barriers.txt translated into
13 BARRERAS DE MEMORIA EN EL KERNEL LINUX
22 Nota: Si tiene alguna duda sobre la exactitud del contenido de esta
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
[all …]
H A Dindex.rst19 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/tools/testing/selftests/arm64/mte/
H A Dmte_common_util.c1 // SPDX-License-Identifier: GPL-2.0
28 void mte_default_handler(int signum, siginfo_t *si, void *uc) in mte_default_handler() argument
30 unsigned long addr = (unsigned long)si->si_addr; in mte_default_handler()
35 ((ucontext_t *)uc)->uc_mcontext.pc, addr, si->si_code); in mte_default_handler()
37 if (si->si_code == SEGV_MTEAERR) { in mte_default_handler()
38 if (cur_mte_cxt.trig_si_code == si->si_code) in mte_default_handler()
42 ((ucontext_t *)uc)->uc_mcontext.pc, in mte_default_handler()
47 else if (si->si_code == SEGV_MTESERR) { in mte_default_handler()
48 if (cur_mte_cxt.trig_si_code == si->si_code && in mte_default_handler()
57 ((ucontext_t *)uc)->uc_mcontext.pc += 4; in mte_default_handler()
[all …]
/linux/Documentation/translations/sp_SP/scheduler/
H A Dsched-eevdf.rst2 .. include:: ../disclaimer-sp.rst
4 :Original: Documentation/scheduler/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.
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"
[all …]
H A Dsched-design-CFS.rst1 .. include:: ../disclaimer-sp.rst
3 :Original: :ref:`Documentation/scheduler/sched-design-CFS.rst <sched_design_CFS>`
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
20 Documentation/scheduler/sched-eevdf.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%
[all …]
/linux/drivers/net/ethernet/freescale/enetc/
H A Denetc_pf.c1 // SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
2 /* Copyright 2017-2019 NXP */
11 #include <linux/pcs-lynx.h>
17 static void enetc_pf_get_primary_mac_addr(struct enetc_hw *hw, int si, u8 *addr) in enetc_pf_get_primary_mac_addr() argument
19 u32 upper = __raw_readl(hw->port + ENETC_PSIPMAR0(si)); in enetc_pf_get_primary_mac_addr()
20 u16 lower = __raw_readw(hw->port + ENETC_PSIPMAR1(si)); in enetc_pf_get_primary_mac_addr()
26 static void enetc_pf_set_primary_mac_addr(struct enetc_hw *hw, int si, in enetc_pf_set_primary_mac_addr() argument
32 __raw_writel(upper, hw->port + ENETC_PSIPMAR0(si)); in enetc_pf_set_primary_mac_addr()
33 __raw_writew(lower, hw->port + ENETC_PSIPMAR1(si)); in enetc_pf_set_primary_mac_addr()
41 if (!is_valid_ether_addr(saddr->sa_data)) in enetc_pf_set_mac_addr()
[all …]

1234