| /linux/Documentation/translations/sp_SP/process/ |
| H A D | management-style.rst | 12 Este es un documento breve que describe el estilo de gestión preferido (o
19 El estilo de gestión es muy personal y mucho más difícil de cuantificar
28 alguna idea sobre el presupuesto de tu grupo, es casi seguro que no eres
32 People” y NO leerlo. Quemarlo, es un gran gesto simbólico.
36 de cuál es la respuesta.
47 más grande debe ser el gerente para tomarla. Eso es muy profundo y obvio,
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**
[all …]
|
| H A D | maintainer-kvm-x86.rst | 4 :Translator: Juan Embid <jembid@ucm.es>
41 tiempo, es decir, que será el statu quo en un futuro previsible.
46 propósito de utilizar ramas temáticas más específicas es facilitar el
54 ``next`` a través de un Cthulhu merge en función de las necesidades, es
61 mainline, suelen aplicarse directamente al árbol principal de KVM, es
89 para ponerse al día en otras tareas, es decir, la falta de envíos durante
90 este periodo no es inusual.
94 expectativas realistas. Si está haciendo ping para la aceptación, es decir,
114 Todo lo demás debería basarse en ``kvm-x86/next``, es decir, no hay
116 conflictos y/o dependencias entre ramas, es trabajo del mantenedor
[all …]
|
| H A D | coding-style.rst | 11 Este es un breve documento que describe el estilo preferido en el código
12 del kernel Linux. El estilo de código es muy personal y no **forzaré** mi
18 GNU, y NO leerlo. Quémelos, es un gran gesto simbólico.
28 de 4 (¡o incluso 2!) caracteres de longitud, y eso es similar a tratar de
31 Justificación: La idea detrás de la sangría es definir claramente dónde
38 pantalla de terminal de 80 caracteres. La respuesta a eso es que si
47 declaración de switch es para alinear el ``switch`` y sus etiquetas
95 del kernel es súper simple. Evite las expresiones engañosas.
111 El límite preferido en la longitud de una sola línea es de 80 columnas.
118 se colocan sustancialmente a la derecha. Un estilo muy usado es alinear
[all …]
|
| H A D | handling-regressions.rst | 10 *No causamos regresiones* -- este documento describe la que es la "primera
32 incidente (esto es opcional, pero recomendado).
76 breve "Reply-all" con la lista en CC; Intentar asegurar que la lista es
91 comando a "regzbot", como ``#regzbot introduced 1f2e3d4c5b6a``. Si no es
97 Esto indica a regzbot el rango de versiones en el cual es defecto
105 seguida. Esto es importante, ya que regzbot buscará más tarde parches
119 Qué es importante cuando se corrigen regresiones
141 Todo esto se espera y es importante en una regresión, ya que estas
146 herramientas es regzbot, el cual depende mucho de las etiquetas "Link:"
249 Evalué cómo de grande es el riesgo de una regresión, por ejemplo realizando
[all …]
|
| H A D | 2.Process.rst | 36 Cada lanzamiento 5.x es un lanzamiento principal del kernel con nuevas
39 varias centenas de miles de líneas de código. 5.x es la vanguardia del
46 momento, el código que se considera lo suficientemente estable (y que es
72 que puede hacer es esperar al siguiente ciclo de desarrollo. (Se hace una
80 punto entre -rc6 y -rc9 antes de que se considere que el kernel es
102 es la lista de regresiones de lanzamientos anteriores. Ningunos errores
105 que causan regresiones se ven con malos ojos y es bastante probable que
108 El objetivo de los desarrolladores es corregir todas las regresiones
110 real, este tipo de perfección es difícil de lograr; hay demasiados
116 ninguna de ellas es seria.
[all …]
|
| H A D | howto.rst | 11 Este documento es el principal punto de partida. Contiene instrucciones
32 es necesario para desarrollar en el kernel. Lenguaje ensamblador (en
33 cualquier arquitectura) no es necesario excepto que planee realizar
34 desarrollo de bajo nivel para dicha arquitectura. Aunque no es un perfecto
54 desarrollo existente. Es un grupo diverso de personas, con altos estándares
86 Esta es la lista de archivos que están en el código fuente del kernel y son
91 describe lo que es necesario hacer para configurar y compilar el
116 dichas reglas, el fracaso es prácticamente garantizado.
134 Este documento es crucial para comprender la filosofía del desarrollo
135 de Linux y es muy importante para las personas que se mudan a Linux
[all …]
|
| H A D | adding-syscalls.rst | 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
49 - Si la operación es específica a un archivo o descriptor de archivo
51 podría ser más apropiada. Sin embargo, :manpage:`fcntl(2)` es una
53 esta opción es mejor cuando la nueva funcion es analogamente cercana a
55 es muy simple (por ejemplo, definir/obtener un flag simple relacionado a
58 - Si la operación es específica a un proceso o tarea particular, entonces
60 como con :manpage:`fcntl(2)`, esta llamada al sistema es un multiplexor
69 ser soportada indefinidamente. Como tal, es una muy buena idea discutir
70 explícitamente el interface en las listas de correo del kernel, y es
[all …]
|
| H A D | 1.Intro.rst | 49 revisores es una parte crucial del proceso de desarrollo; esta sección
70 existen y todo tipo de sistemas intermedios. Es una solución robusta,
85 Una de las características más convincentes de Linux es que es accesible
88 productos propietarios no pueden ofrecer este tipo de apertura, que es una
90 kernel es aún más libre que la mayoría de los otros proyectos de software
95 Trabajar con la comunidad de desarrollo del kernel no es especialmente
101 se cambian todos los días. Por lo tanto, no es sorprendente que el
110 desarrollo, si bien es servicial para aquellos que están tratando de
138 kernel y obtener su código en el kernel mainline (el “mainline” es el
142 y dar soporte a los usuarios directamente. La verdad del asunto es que
[all …]
|
| H A D | submitting-patches.rst | 13 familiarizado con "el sistema". Este texto es una colección de sugerencias
44 Tenga en cuenta, sin embargo, que es posible que no desee desarrollar con
84 al respecto en detalles técnicos. Es importante describir el cambio en
94 larga, eso es una señal de que probablemente necesite dividir su parche.
99 decir que esa es la versión N del parche (serie). No espere que el
102 parche. Es decir, el parche (serie) y su descripción deben ser
134 parche es el resultado de alguna discusión anterior de la lista de correo o
193 El punto a recordar es que cada parche debe realizar un cambio que puede
220 Una excepción importante es cuando se mueve código de un archivo a otro.
229 del juicio humano. Si su código es mejor con una violación entonces
[all …]
|
| H A D | researcher-guidelines.rst | 40 de Linux es bienvenida, aunque la investigación sobre los desarrolladores
45 las contribuciones a los repositorios públicos, es claramente permitida.
53 esto también es ética de investigación estándar.
55 Para ayudar a aclarar: enviar parches a los desarrolladores es interactuar
67 investigadores, como con cualquiera, es bienvenida y alentada. La
68 investigación del código de Linux es una práctica común, especialmente
74 Linux ya tiene muchos errores conocidos – lo que es mucho más útil es
87 * ¿Cuál es el problema específico que se ha encontrado?
96 * ¿Que se cambió para solucionar el problema y por qué se cree es correcto?
103 Por ejemplo (en inglés, pues es en las listas)::
[all …]
|
| H A D | security-bugs.rst | 20 electrónico en <security@kernel.org>. Esta es una lista privada de
24 el proceso. Es posible que el equipo de seguridad traiga ayuda adicional
31 si no tiene claro que información es útil. Cualquier código de explotación
32 es muy útil y no será divulgado sin el consentimiento del "reportero" (el
36 adjuntos cuando sea posible. Es mucho más difícil tener una discusión
47 La lista de seguridad no es un canal de divulgación. Para eso, ver
52 Aunque nuestra preferencia es lanzar soluciones para errores no divulgados
58 solución es para acomodar la logística de QA y los despliegues a gran
68 En otras palabras, nuestro único interés es solucionar los errores. Toda
102 El equipo de seguridad del kernel de Linux no es un organismo formal y,
|
| H A D | deprecated.rst | 15 la jerarquía de mantenimiento, y el tiempo, no siempre es posible hacer
28 porque uno de los objetivos del kernel es que compile sin avisos, y
30 que usar `__deprecated` es sencillo para anotar una API obsoleta en
31 un archivo de cabecera, no es la solución completa. Dichos interfaces
68 De todos modos, el método recomendado en estos caso es reescribir el código
88 Otro caso común a evitar es calcular el tamaño de una estructura com
137 es la función strscpy(), aunque se ha de tener cuidado con cualquier caso
149 destino si la cadena de origen es más corta que el buffer de destino, lo
154 el mejor reemplazo es usar la función strscpy(), aunque se ha de tener
175 carácter NUL. El reemplazo seguro de esta función es strscpy(), pero se ha
[all …]
|
| H A D | embargoed-hardware-issues.rst | 30 El equipo de seguridad de hardware del kernel de Linux es separado del
41 <hardware-security@kernel.org>. Esta es una lista privada de oficiales de
76 contrato de trabajo. El personal de IT de la Fundación Linux también es
81 Linux es Konstantin Ryabitsev.
86 El equipo de seguridad de hardware del kernel de Linux no es un organismo
88 divulgación. La comunidad del kernel es consciente de la naturaleza
120 delincuente de problemas futuros. El impacto de esta consecuencia es un
178 - Si un experto que se requiere para manejar un problema es empleado por
191 suele ser un punto de partida suficiente y es mejor hacer aclaraciones
198 reutiliza una existente si es apropiada.
[all …]
|
| H A D | magic-number.rst | 11 Este archivo es un registro de los números mágicos que están en uso. Cuando
13 este documento, ya que es mejor si los números mágicos utilizados por
16 Es una muy buena idea proteger las estructuras de datos del kernel con
19 a una rutina. Esto último es especialmente útil --- particularmente cuando
25 La forma de usar números mágicos es declararlos al principio de la
51 estamos en fase de "feature freeze", es muy poco probable que
60 freeze, pero es posible que algunos nuevos números mágicos se cuelen en
|
| /linux/fs/exfat/ |
| H A D | dir.c | 36 struct exfat_entry_set_cache es; in exfat_get_uniname_from_ext_entry() local
39 err = exfat_get_dentry_set(&es, sb, p_dir, entry, ES_ALL_ENTRIES); in exfat_get_uniname_from_ext_entry()
49 for (i = ES_IDX_FIRST_FILENAME; i < es.num_entries; i++) { in exfat_get_uniname_from_ext_entry()
50 struct exfat_dentry *ep = exfat_get_dentry_cached(&es, i); in exfat_get_uniname_from_ext_entry()
63 exfat_put_dentry_set(&es, false); in exfat_get_uniname_from_ext_entry()
434 void exfat_init_dir_entry(struct exfat_entry_set_cache *es, in exfat_init_dir_entry() argument
438 struct super_block *sb = es->sb; in exfat_init_dir_entry()
442 ep = exfat_get_dentry_cached(es, ES_IDX_FILE); in exfat_init_dir_entry()
461 ep = exfat_get_dentry_cached(es, ES_IDX_STREAM); in exfat_init_dir_entry()
484 void exfat_init_ext_entry(struct exfat_entry_set_cache *es, int num_entries, in exfat_init_ext_entry() argument
[all …]
|
| /linux/fs/ext2/ |
| H A D | super.c | 55 struct ext2_super_block *es = sbi->s_es; in ext2_error() local
60 es->s_state |= cpu_to_le16(EXT2_ERROR_FS); in ext2_error()
62 ext2_sync_super(sb, es, 1); in ext2_error()
132 struct ext2_super_block *es = EXT2_SB(sb)->s_es; in ext2_update_dynamic_rev() local
134 if (le32_to_cpu(es->s_rev_level) > EXT2_GOOD_OLD_REV) in ext2_update_dynamic_rev()
142 es->s_first_ino = cpu_to_le32(EXT2_GOOD_OLD_FIRST_INO); in ext2_update_dynamic_rev()
143 es->s_inode_size = cpu_to_le16(EXT2_GOOD_OLD_INODE_SIZE); in ext2_update_dynamic_rev()
144 es->s_rev_level = cpu_to_le32(EXT2_DYNAMIC_REV); in ext2_update_dynamic_rev()
145 /* leave es->s_feature_*compat flags alone */ in ext2_update_dynamic_rev()
146 /* es->s_uuid will be set by e2fsck if empty */ in ext2_update_dynamic_rev()
[all …]
|
| /linux/drivers/net/can/usb/kvaser_usb/ |
| H A D | kvaser_usb_leaf.c | 1109 const struct kvaser_usb_err_summary *es, in kvaser_usb_leaf_rx_error_update_can_state() argument
1117 netdev_dbg(priv->netdev, "Error status: 0x%02x\n", es->status); in kvaser_usb_leaf_rx_error_update_can_state()
1122 if (es->status & (M16C_STATE_BUS_OFF | M16C_STATE_BUS_RESET)) { in kvaser_usb_leaf_rx_error_update_can_state()
1124 } else if (es->status & M16C_STATE_BUS_PASSIVE) { in kvaser_usb_leaf_rx_error_update_can_state()
1126 } else if ((es->status & M16C_STATE_BUS_ERROR) && in kvaser_usb_leaf_rx_error_update_can_state()
1129 } else if (es->txerr >= 128 || es->rxerr >= 128) { in kvaser_usb_leaf_rx_error_update_can_state()
1131 } else if (es->txerr >= 96 || es->rxerr >= 96) { in kvaser_usb_leaf_rx_error_update_can_state()
1154 tx_state = (es->txerr >= es->rxerr) ? new_state : 0; in kvaser_usb_leaf_rx_error_update_can_state()
1155 rx_state = (es->txerr <= es->rxerr) ? new_state : 0; in kvaser_usb_leaf_rx_error_update_can_state()
1167 if (es->leaf.error_factor) { in kvaser_usb_leaf_rx_error_update_can_state()
[all …]
|
| /linux/tools/arch/x86/lib/ |
| H A D | x86-opcode-map.txt | 26 # (es): this opcode requires EVEX prefix and is SCALABALE.
57 06: PUSH ES (i64)
58 07: POP ES (i64)
91 26: SEG=ES (Prefix)
942 01: ADD Ev,Gv (es) | ADD Ev,Gv (66),(es)
944 03: ADD Gv,Ev (es) | ADD Gv,Ev (66),(es)
946 09: OR Ev,Gv (es) | OR Ev,Gv (66),(es)
948 0b: OR Gv,Ev (es) | OR Gv,Ev (66),(es)
950 11: ADC Ev,Gv (es) | ADC Ev,Gv (66),(es)
952 13: ADC Gv,Ev (es) | ADC Gv,Ev (66),(es)
[all …]
|
| /linux/arch/x86/lib/ |
| H A D | x86-opcode-map.txt | 26 # (es): this opcode requires EVEX prefix and is SCALABALE.
57 06: PUSH ES (i64)
58 07: POP ES (i64)
91 26: SEG=ES (Prefix)
942 01: ADD Ev,Gv (es) | ADD Ev,Gv (66),(es)
944 03: ADD Gv,Ev (es) | ADD Gv,Ev (66),(es)
946 09: OR Ev,Gv (es) | OR Ev,Gv (66),(es)
948 0b: OR Gv,Ev (es) | OR Gv,Ev (66),(es)
950 11: ADC Ev,Gv (es) | ADC Ev,Gv (66),(es)
952 13: ADC Gv,Ev (es) | ADC Gv,Ev (66),(es)
[all …]
|
| /linux/scripts/coccinelle/iterators/ |
| H A D | for_each_child.cocci | 25 expression list [n1] es;
47 i(es,n,...) S
55 expression list [r.n1] es;
59 i(es,n,...) {
84 expression list [r.n1] es;
88 i(es,n,...) {
117 expression list [r.n1] es;
121 i(es,n,...) {
150 expression list[r.n1] es;
156 i@j0(es,n,...) {
[all …]
|
| /linux/drivers/parisc/ |
| H A D | eisa_enumerator.c | 314 struct eeprom_eisa_slot_info *es, in parse_slot_config() argument
332 print_eisa_id(board, es->eisa_slot_id); in parse_slot_config()
334 slot, board, es->flags&HPEE_FLAG_BOARD_IS_ISA ? "ISA" : "EISA"); in parse_slot_config()
336 maxlen = es->config_data_length < HPEE_MAX_LENGTH ? in parse_slot_config()
337 es->config_data_length : HPEE_MAX_LENGTH; in parse_slot_config()
338 while ((pos < maxlen) && (num_func <= es->num_functions)) { in parse_slot_config()
409 if (pos != es->config_data_length) { in parse_slot_config()
411 pos, es->config_data_length); in parse_slot_config()
415 if (num_func != es->num_functions) { in parse_slot_config()
417 num_func, es->num_functions); in parse_slot_config()
[all …]
|
| /linux/scripts/coccinelle/misc/ |
| H A D | warn.cocci | 45 expression list es;
51 es);
55 expression list ok1.es;
60 WARN(1,es);
94 expression list es;
100 es);
104 expression list ok2.es;
109 WARN_ONCE(1,es);
|
| /linux/drivers/net/ethernet/intel/ice/ |
| H A D | ice_flex_pipe.c | 631 if (prof >= hw->blk[blk].es.count) in ice_find_prot_off()
634 if (fv_idx >= hw->blk[blk].es.fvw) in ice_find_prot_off()
637 fv_ext = hw->blk[blk].es.t + (prof * hw->blk[blk].es.fvw); in ice_find_prot_off()
787 u16 es; /* # extraction sequence entries */ member
1171 if (hw->blk[blk].es.mask_ena[prof] & BIT(i)) in ice_prof_has_mask_idx()
1203 /* es->mask_ena[prof] will have the mask */ in ice_prof_has_mask()
1204 for (i = 0; i < hw->blk[blk].es.fvw; i++) in ice_prof_has_mask()
1225 struct ice_es *es = &hw->blk[blk].es; in ice_find_prof_id_with_mask() local
1234 for (i = 0; i < (u8)es->count; i++) { in ice_find_prof_id_with_mask()
1235 u16 off = i * es->fvw; in ice_find_prof_id_with_mask()
[all …]
|
| /linux/Documentation/translations/sp_SP/ |
| H A D | index.rst | 17 El objetivo de esta traducción es facilitar la lectura y comprensión para
20 embargo, tenga en cuenta que la *única* documentación oficial es la que
24 :ref:`linux_doc` es altamente improbable. Los maintainers y colaboradores
26 es posible. Por tanto, no existe ninguna garantía de que una traducción
32 Una traducción no es una * bifurcación * de la documentación oficial, por
41 Las traducciones tratan de ser lo más precisas posible pero no es posible
64 Este es el nivel superior de la documentación del kernel en idioma español.
65 La traducción es incompleta, y podría encontrar advertencias que indiquen
|
| H A D | memory-barriers.txt | 23 traducción, la única referencia válida es la documentación oficial en
30 Este documento no es una especificación; es intencionalmente (por motivos
39 De nuevo, este documento no es una especificación de lo que Linux espera
42 El propósito de este documento es doble:
51 arquitectura proporciona menos de eso, dicha arquitectura es incorrecta.
53 Tenga en cuenta también que es posible que una barrera no valga (sea no-op)
152 En la CPU abstracta, el orden de las operaciones de memoria es muy
173 organizar en 24 combinaciones diferentes (donde LOAD es cargar y STORE es
222 de control es muy importante. Por ejemplo, imagine una tarjeta ethernet con
249 donde READ_ONCE() es LEER_UNA_VEZ(), la CPU emitirá las siguientes
[all …]
|