/linux/Documentation/translations/sp_SP/process/ |
H A D | 1.Intro.rst | 14 El resto de esta sección cubre el alcance del proceso de desarrollo del 16 empleadores pueden encontrar allí. Hay muchas razones por las que el 17 código del kernel debe fusionarse con el kernel oficial (“mainline”), 18 incluyendo la disponibilidad automática para los usuarios, el apoyo de la 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 25 (merge window). Se cubren las distintas fases en el desarrollo del parche, 26 la revisión y, el ciclo de fusión. Hay algunas discusiones sobre 28 comenzar con el desarrollo del kernel a encontrar y corregir errores como 35 :ref:`sp_development_coding` trata sobre el proceso de codificación. Se [all …]
|
H A 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 14 alrededor de 2,000 desarrolladores involucrados durante un año, el kernel 15 ha tenido que adaptar varios procesos para mantener el desarrollo sin 16 problemas. Se requiere una comprensión solida de cómo funciona el proceso 19 El panorama general 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 40 desarrollo del kernel de Linux; el kernel utiliza un modelo de desarrollo 46 momento, el código que se considera lo suficientemente estable (y que es [all …]
|
H A D | embargoed-hardware-issues.rst | 30 El equipo de seguridad de hardware del kernel de Linux es separado del 33 El equipo solo maneja la coordinación de los problemas de seguridad de 35 en el kernel de Linux no son manejados por este equipo y el "reportero" 36 (quien informa del error) será guiado a contactar el equipo de seguridad 40 El equipo puede contactar por correo electrónico en 45 La lista esta encriptada y el correo electrónico a la lista puede ser 47 PGP del reportero o el certificado de S/MIME. La llave de PGP y el 55 el vendedor de hardware afectado, damos la bienvenida al contacto de 62 El equipo actual de oficiales de seguridad de hardware: 76 contrato de trabajo. El personal de IT de la Fundación Linux también es [all …]
|
H A 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á 13 familiarizado con "el sistema". Este texto es una colección de sugerencias 19 funciona el proceso de desarrollo del kernel, consulte 35 Obtenga el código fuente actual 38 Si no tiene a mano un repositorio con el código fuente actual del kernel, 39 use ``git`` para obtener uno. Querrá comenzar con el repositorio principal, 45 el árbol principal directamente. La mayoría de los maintainers de 47 preparados para esos árboles. Revise el campo **T:** para el subsistema 48 en el archivo MAINTAINERS para encontrar dicho árbol, o simplemente [all …]
|
H A D | handling-regressions.rst | 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 17 Las partes importantes (el "TL;DR") 31 #. Haga que el bot del kernel de Linux "regzbot" realice el seguimiento del 37 como el siguiente, lo que le indica a regzbot cuando empezó a suceder 38 el incidente:: 43 regresiones(ver más arriba), incluir un párrafo como el siguiente:: 51 del incidente, como se indica en el documento: 69 Asegúrese de que el programa de gestión de regresiones del kernel de Linux 75 inmediatamente meterla en el la cadena de emails mandado al menos un [all …]
|
H A 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 13 trabajar con el y en su desarrollo. El documento no tratará ningún aspecto 15 guiándole por el camino correcto. 24 Linux para este dispositivo." El objetivo de este documento en enseñarle 25 todo cuanto necesita para conseguir esto, describiendo el proceso por el 30 El kernel esta principalmente escrito en C, con algunas partes que son 32 es necesario para desarrollar en el kernel. Lenguaje ensamblador (en 42 El kernel está escrito usando GNU C y la cadena de herramientas GNU. Si 44 no aparecen en dicho estándar. El kernel usa un C independiente de entorno, [all …]
|
H A D | maintainer-kvm-x86.rst | 29 x86 está dividido entre el árbol principal de KVM, 33 Por lo general, las correcciones para el ciclo en curso se aplican 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 36 improbable caso de que una corrección para el ciclo actual se dirija a 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 46 propósito de utilizar ramas temáticas más específicas es facilitar el 48 errores humanos y/o commits con errores, por ejemplo, borrar el commit HEAD 62 decir, no pasan por el árbol x86 de KVM. [all …]
|
H A D | deprecated.rst | 15 la jerarquía de mantenimiento, y el tiempo, no siempre es posible hacer 17 han de ir creándose en el kernel, mientras que las antiguas se quitan, 21 obsoletos son propuestos para incluir en el kernel. 33 desanimar a otros a usarla en el futuro. 43 estados?). La popular función BUG() desestabilizará el sistema o lo romperá 64 que se realicen reservas de memoria menores que las que se esperaban. El 65 uso de esas reservas puede llevar a desbordamientos en el 'heap' de memoria 67 literales donde el compilador si puede avisar si estos puede desbordarse. 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 [all …]
|
H A 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 12 del kernel Linux. El estilo de código es muy personal y no **forzaré** mi 29 definir el valor de PI como 3. 37 el código se mueva demasiado a la derecha y dificulta la lectura en una 47 declaración de switch es para alinear el ``switch`` y sus etiquetas 78 No use comas para evitar el uso de llaves: 94 Tampoco ponga varias asignaciones en una sola línea. El estilo de código 99 espacios nunca se utilizan para la sangría, y el ejemplo anterior se rompe 108 El estilo de código tiene todo que ver con la legibilidad y la [all …]
|
H A D | email-clients.rst | 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, 28 preferiblemente como texto en línea en el cuerpo del correo electrónico. 32 partes del parche sea más difícil durante el proceso de revisión del 35 También se recomienda encarecidamente que utilice texto sin formato en el 43 kernel Linux deben enviar el texto del parche intacto. Por ejemplo, no 60 encabezados "References:" o "In-Reply-To:" para que el hilo de correo no 68 No utilice firmas PGP/GPG en el correo que contiene parches. 72 Es una buena idea enviarse un parche a sí mismo, guardar el mensaje [all …]
|
H A D | adding-syscalls.rst | 21 son los puntos de interacción entre el userspace y el kernel más obvios y 31 - Si la nueva funcionalidad involucra operaciones donde el kernel 33 descriptor de archivo para el objeto relevante permite al userspace 42 (mire ``Documentation/filesystems/sysfs.rst``) o el filesystem ``/proc`` 44 requiere que el filesystem relevante esté montado, lo que podría no ser 45 siempre el caso (e.g. en un ambiente namespaced/sandboxed/chrooted). 47 interfaz (interface) de 'producción' para el userspace. 65 Diseñando el API: Planeando para extensiones 70 explícitamente el interface en las listas de correo del kernel, y es 77 historia del kernel y planee extensiones desde el inicio.) [all …]
|
H A D | security-bugs.rst | 19 El equipo de seguridad del kernel de Linux puede ser contactado por correo 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 29 más fácil será diagnosticarlo y corregirlo. Por favor, revise el 32 es muy útil y no será divulgado sin el consentimiento del "reportero" (el 33 que envia el error) a menos que ya se haya hecho público. 40 un parche todavía) describa el problema y el impacto, enumere los pasos 49 comienza el proceso de lanzamiento. Las soluciones para errores conocidos 55 desde el inicio del proceso de lanzamiento, con una extensión excepcional 63 junto con la solución o en cualquier otro canal de divulgación sin el [all …]
|
H A D | management-style.rst | 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. 14 Está destinado a reflejar el documento 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 35 haciendo dolorosamente obvio para el interrogador que no tenemos ni idea 47 más grande debe ser el gerente para tomarla. Eso es muy profundo y obvio, 50 El nombre del partido es **evitar** tener que tomar una decisión. En 59 diferente. Es decir, que estas en el trabajo equivocado y que **ellos** 62 Así que el nombre del partido es **evitar** las decisiones, al menos las [all …]
|
H A D | researcher-guidelines.rst | 10 transparente sobre el kernel de Linux, las actividades involucradas 37 el proyecto están participando en buena fe para mejorar Linux. La 49 La investigación activa sobre el comportamiento de los desarrolladores, 50 sin embargo, debe hacerse con el acuerdo explícito y la divulgación 60 ejemplo, agotar el tiempo, el esfuerzo, y la moral) y perjudicial para el 62 el colaborador (y la organización del colaborador en conjunto), socavando 66 La participación en el desarrollo de Linux en sí mismo por parte de 87 * ¿Cuál es el problema específico que se ha encontrado? 89 * ¿Qué efecto tendría encontrar el problema en el sistema? 90 * ¿Como se encontró el problema? Incluya específicamente detalles sobre [all …]
|
H A D | kernel-enforcement-statement.rst | 8 Aplicación de la licencia en el kernel Linux 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 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 24 el siguiente compromiso con los usuarios del kernel Linux, en nombre 28 que es en el mejor interés de nuestra comunidad de desarrollo adoptar 36 a menos que y hasta que el titular de los derechos de autor explícita [all …]
|
H A D | programming-language.rst | 11 El kernel está escrito en el lenguaje de programación C [sp-c-language]_. 12 Más concretamente, el kernel normalmente se compila con ``gcc`` [sp-gcc]_ 13 bajo ``-std=gnu11`` [sp-gcc-c-dialect-options]_: el dialecto GNU de ISO C11. 20 Hay algo de soporte para compilar el núcleo con ``icc`` [sp-icc]_ para varias 21 de las arquitecturas, aunque en el momento de escribir este texto, eso no 27 Una de las comunes extensiones utilizadas en todo el kernel son los atributos 34 que no los admiten pero de todos modos deben producir el código adecuado, 38 El kernel define pseudo-palabras clave (por ejemplo, ``__pure``) en lugar 40 ``__attribute__((__pure__))``) con el fin de detectar cuáles se pueden 41 utilizar y/o acortar el código.
|
H A D | contribution-maturity-model.rst | 17 en el reclutamiento de mantenedores del kernel, así como la sucesión de 34 El TAB insta a las organizaciones a evaluar continuamente su modelo de 38 y los desarrolladores en todos los niveles de antigüedad. En el espíritu 84 * El número de contribuciones al kernel upstream por equipo u 87 * El porcentaje de desarrolladores del kernel que han realizado 90 * El intervalo de tiempo entre los kernels utilizados en los servidores 92 upstream en el que se basa el kernel interno. 93 * El número de commits fuera del árbol de desarrollo presentes en los 100 trabajo centrado en el Trabajo Ascendente, que se define como revisar 112 * El desarrollo del kernel upstream se considera un puesto de trabajo [all …]
|
H A D | submit-checklist.rst | 19 1) Si utiliza una funcionalidad, #include el archivo que define/declara 44 5) Verifique su parche para el estilo general según se detalla en 46 Verifique las infracciones triviales con el verificador de estilo de 51 6) Cualquier opción ``CONFIG`` nueva o modificada no altera el menú de 70 candidata para el cambio. 75 para comprobar el :ref:`kernel-doc <kernel_doc>` y solucionar 107 Si el nuevo código es sustancial, la adición de la inyección de 110 20) El nuevo código añadido ha sido compilado con ``gcc -W`` (use 114 21) Se prueba después de que se haya fusionado en el conjunto de 119 ``wmb()``} necesitan un comentario en el código fuente que explique [all …]
|
/linux/Documentation/translations/sp_SP/scheduler/ |
H A D | sched-design-CFS.rst | 16 ("Completely Fair Scheduler"), y es el nuevo gestor de tareas de escritorio 17 implementado por Ingo Molnar e integrado en Linux 2.6.23. Es el sustituto 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 33 se ha usado el concepto de "tiempo de ejecución virtual". El tiempo 36 En la práctica, el tiempo de ejecución virtual de una tarea es el 44 En CFS, el tiempo de ejecución virtual se expresa y se monitoriza por 46 De este modo, es posible temporizar con precisión y medir el "tiempo 50 tareas pueden tener el mismo valor de p->se.vruntime --- i.e., tareas 54 La lógica de elección del tareas de CFS se basa en el valor de p->se.vruntime [all …]
|
/linux/Documentation/translations/sp_SP/ |
H A D | memory-barriers.txt | 13 BARRERAS DE MEMORIA EN EL KERNEL LINUX 42 El propósito de este documento es doble: 49 Tenga en cuenta que una arquitectura puede proporcionar más que el 112 - Y luego está el Alfa. 126 Considere el siguiente modelo abstracto del sistema: 152 En la CPU abstracta, el orden de las operaciones de memoria es muy 154 en el orden que desee, siempre que la causalidad del programa parezca 155 mantenerse. De manera similar, el compilador también puede organizar las 156 instrucciones que emite en el orden que quiera, siempre que no afecte al 159 Entonces, en el diagrama anterior, los efectos de las operaciones de [all …]
|
/linux/Documentation/RCU/ |
H A D | rcuref.rst | 26 atomic_set(&el->rc, 1); atomic_inc(&el->rc); 37 if(atomic_dec_and_test(&el->rc)) ... 38 kfree(el); 42 if (atomic_dec_and_test(&el->rc)) 43 kfree(el); 61 atomic_set(&el->rc, 1); if (!atomic_inc_not_zero(&el->rc)) { 72 if (atomic_dec_and_test(&el->rc)) ... 73 call_rcu(&el->head, el_free); remove_element 76 if (atomic_dec_and_test(&el->rc)) 77 call_rcu(&el->head, el_free); [all …]
|
/linux/fs/ocfs2/ |
H A D | alloc.c | 586 node->el = NULL; in ocfs2_reinit_path() 629 dest->p_node[i].el = src->p_node[i].el; in ocfs2_cp_path() 651 dest->p_node[i].el = src->p_node[i].el; in ocfs2_mv_path() 654 src->p_node[i].el = NULL; in ocfs2_mv_path() 677 path->p_node[index].el = &eb->h_list; in ocfs2_path_insert_eb() 766 int ocfs2_search_extent_list(struct ocfs2_extent_list *el, u32 v_cluster) in ocfs2_search_extent_list() argument 773 for(i = 0; i < le16_to_cpu(el->l_next_free_rec); i++) { in ocfs2_search_extent_list() 774 rec = &el->l_recs[i]; in ocfs2_search_extent_list() 777 clusters = ocfs2_rec_clusters(el, rec); in ocfs2_search_extent_list() 951 struct ocfs2_extent_list *el = NULL; in ocfs2_num_free_extents() local [all …]
|
/linux/fs/gfs2/ |
H A D | xattr.c | 191 struct gfs2_ea_location *el = ef->ef_el; in ea_find_i() local 193 el->el_bh = bh; in ea_find_i() 194 el->el_ea = ea; in ea_find_i() 195 el->el_prev = prev; in ea_find_i() 204 struct gfs2_ea_location *el) in gfs2_ea_find() argument 212 ef.ef_el = el; in gfs2_ea_find() 214 memset(el, 0, sizeof(struct gfs2_ea_location)); in gfs2_ea_find() 522 static int gfs2_ea_get_copy(struct gfs2_inode *ip, struct gfs2_ea_location *el, in gfs2_ea_get_copy() argument 526 size_t len = GFS2_EA_DATA_LEN(el->el_ea); in gfs2_ea_get_copy() 530 if (GFS2_EA_IS_STUFFED(el->el_ea)) { in gfs2_ea_get_copy() [all …]
|
/linux/lib/ |
H A D | test_list_sort.c | 61 struct debug_el *el, **elts; in list_sort_test() local 70 el = kunit_kmalloc(test, sizeof(*el), GFP_KERNEL); in list_sort_test() 71 KUNIT_ASSERT_NOT_ERR_OR_NULL(test, el); in list_sort_test() 74 el->value = get_random_u32_below(TEST_LIST_LEN / 3); in list_sort_test() 75 el->serial = i; in list_sort_test() 76 el->poison1 = TEST_POISON1; in list_sort_test() 77 el->poison2 = TEST_POISON2; in list_sort_test() 78 elts[i] = el; in list_sort_test() 79 list_add_tail(&el->list, &head); in list_sort_test() 94 el = container_of(cur, struct debug_el, list); in list_sort_test() [all …]
|
/linux/drivers/crypto/hisilicon/sec/ |
H A D | sec_algs.c | 373 static void sec_alg_free_el(struct sec_request_el *el, in sec_alg_free_el() argument 376 sec_free_hw_sgl(el->out, el->dma_out, info); in sec_alg_free_el() 377 sec_free_hw_sgl(el->in, el->dma_in, info); in sec_alg_free_el() 378 kfree(el->sgl_in); in sec_alg_free_el() 379 kfree(el->sgl_out); in sec_alg_free_el() 380 kfree(el); in sec_alg_free_el() 386 struct sec_request_el *el, *temp; in sec_send_request() local 390 list_for_each_entry_safe(el, temp, &sec_req->elements, head) { in sec_send_request() 404 ret = sec_queue_send(queue, &el->req, sec_req); in sec_send_request() 412 kfifo_put(&queue->softqueue, el); in sec_send_request() [all …]
|