| /linux/fs/ocfs2/ |
| H A D | alloc.c | 587 node->el = NULL; in ocfs2_reinit_path()
630 dest->p_node[i].el = src->p_node[i].el; in ocfs2_cp_path()
652 dest->p_node[i].el = src->p_node[i].el; in ocfs2_mv_path()
655 src->p_node[i].el = NULL; in ocfs2_mv_path()
678 path->p_node[index].el = &eb->h_list; in ocfs2_path_insert_eb()
767 int ocfs2_search_extent_list(struct ocfs2_extent_list *el, u32 v_cluster) in ocfs2_search_extent_list() argument
774 for(i = 0; i < le16_to_cpu(el->l_next_free_rec); i++) { in ocfs2_search_extent_list()
775 rec = &el->l_recs[i]; in ocfs2_search_extent_list()
778 clusters = ocfs2_rec_clusters(el, rec); in ocfs2_search_extent_list()
952 struct ocfs2_extent_list *el = NULL; in ocfs2_num_free_extents() local
[all …]
|
| H A D | extent_map.c | 281 struct ocfs2_extent_list *el; in ocfs2_last_eb_is_empty() local
290 el = &eb->h_list; in ocfs2_last_eb_is_empty()
292 if (el->l_tree_depth) { in ocfs2_last_eb_is_empty()
301 next_free = le16_to_cpu(el->l_next_free_rec); in ocfs2_last_eb_is_empty()
304 (next_free == 1 && ocfs2_is_empty_extent(&el->l_recs[0]))) in ocfs2_last_eb_is_empty()
316 static int ocfs2_search_for_hole_index(struct ocfs2_extent_list *el, in ocfs2_search_for_hole_index() argument
322 for(i = 0; i < le16_to_cpu(el->l_next_free_rec); i++) { in ocfs2_search_for_hole_index()
323 rec = &el->l_recs[i]; in ocfs2_search_for_hole_index()
344 struct ocfs2_extent_list *el, in ocfs2_figure_hole_clusters() argument
353 i = ocfs2_search_for_hole_index(el, v_cluster); in ocfs2_figure_hole_clusters()
[all …]
|
| /linux/Documentation/translations/sp_SP/process/ |
| H A 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
27 problema. Sin embargo, si el trabajo que se está realizando es complejo,
29 se complete el trabajo. Por lo tanto, se debería considerar publicar
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
48 de depuración del kernel, asegúrese de que el kernel se compilará con
56 puntos de referencia que muestren cuál es el impacto (o beneficio) de
57 su cambio; se debe incluir un resumen de los resultados con el parche.
59 - Asegúrese de que tiene derecho a publicar el código. Si este trabajo
[all …]
|
| 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
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
41 :ref:`sp_development_posting` trata sobre el proceso de enviar parches para
[all …]
|
| H A D | 2.Process.rst | 8 Cómo funciona el proceso de desarrollo
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
23 en el tiempo de manera flexible, con uno nuevo lanzamiento principal del
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
47 aceptado por la comunidad de desarrollo) se fusiona en el kernel mainline.
60 el primero de los kernels “rc”. Para el kernel destinado a ser 5.6, por
61 ejemplo, el lanzamiento al final de la ventana de fusión se llamará
[all …]
|
| H A D | 4.Coding.rst | 8 Conseguir el código correcto
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.
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
20 errores. Luego, el enfoque se dirigirá hacia hacer las cosas bien y las
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.
40 kernel es muy difícil si ese código no está escrito de acuerdo con el
41 estándar; muchos desarrolladores solicitarán que el código sea reformateado
[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 | 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 | 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á
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
105 size_add(), and size_sub(). Por ejemplo, en el caso de::
[all …]
|
| H A D | embargoed-hardware-issues.rst | 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
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
77 responsable para operar y administrar el resto de la infraestructura de
101 seguridad del hardware en el pasado y tiene los mecanismos necesarios para
102 permitir el desarrollo compatible con la comunidad bajo restricciones de
106 dedicado para el contacto inicial, el cual supervisa el proceso de manejo
110 (expertos en dominio) que formarán el equipo de respuesta inicial para un
[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 | 7.AdvancedTopics.rst | 11 Llegados a este punto, con suerte, tiene una idea de cómo funciona el
20 El uso del control de versiones distribuido para el kernel comenzó a
22 propietaria BitKeeper. Aunque BitKeeper fue controvertido, el enfoque de
26 varias alternativas gratuitas a BitKeeper. Para bien o para mal, el
29 Administrar parches con git puede hacer la vida mucho más fácil para el
30 desarrollador, especialmente a medida que crece el volumen de esos
35 derecho propio. En su lugar, el enfoque aquí será cómo git encaja en el
48 capaz de obtener una copia del repositorio mainline, explorar el historial
49 de revisiones, hacer commits en el árbol, usar ramas, etcétera. También es
52 usuario de git debe conocer las referencias, las ramas remotas, el índice,
[all …]
|
| H A D | 3.Early-stage.rst | 18 Especificar el problema
24 específico, por ejemplo. En otros, sin embargo, es tentador confundir el
30 el sistema. La solución a la que llegaron fue un módulo del kernel
31 destinado a integrarse en el marco del Módulo de Seguridad de Linux (LSM,
42 preferidas implicaban el acceso a la programación en tiempo real a través
49 desilusionados con todo el proceso de desarrollo del kernel; uno de ellos
54 Siendo el texto original:
64 estaban mucho más preocupados por la estabilidad del sistema, el
66 que por un módulo específico. La moraleja de la historia es centrarse en el
73 - ¿Cuál es exactamente el problema que necesita ser resuelto?
[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.
25 todo cuanto necesita para conseguir esto, describiendo el proceso por el
32 es necesario para desarrollar en el kernel. Lenguaje ensamblador (en
48 entender las suposiciones que el kernel hace respecto a la cadena de
65 favor, revise el archivo COPYING, presente en la carpeta principal del
81 cómo usar la función. Cuando un cambio en el kernel hace que la interfaz
82 que el kernel expone espacio de usuario cambie, se recomienda que envíe la
[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 | 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.
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.
69 el pull request principal de KVM enviado durante la ventana de fusión de
[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
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:
99 espacios nunca se utilizan para la sangría, y el ejemplo anterior se rompe
117 Los descendientes siempre son sustancialmente más cortos que el padre y
124 Sin embargo, nunca rompa los strings visibles para el usuario, como los
131 El otro problema que siempre surge en el estilo C es la colocación de
[all …]
|
| H A D | 6.Followthrough.rst | 31 otros desarrolladores a medida que revisan el código. Trabajar con los
45 relativamente ingrata; la gente recuerda quién escribió el código del
49 parece enojada, insultante o abiertamente ofensiva, resista el impulso de
56 del kernel a menudo esperan estar trabajando en el kernel dentro de
62 - Esté preparado para solicitudes aparentemente ridículas de cambios en el
65 …maintainers es mantener las cosas con una apariencia uniforme. A veces, esto significa que el truc…
70 comentarios de revisión sobre un parche, tómese el tiempo para entender lo
71 que el revisor está tratando de decir. Si es posible, arregle las cosas que
72 el revisor le está pidiendo que corrija. Y responda al revisor:
76 por los revisores. Si cree que el revisor ha malinterpretado su código,
[all …]
|
| /linux/lib/tests/ |
| 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/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/Documentation/translations/sp_SP/ |
| H A D | memory-barriers.txt | 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
160 memoria realizadas por un CPU son percibidos por el resto del sistema a
161 medida que las operaciones cruzan la interfaz entre la CPU y el resto del
[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/Documentation/translations/sp_SP/scheduler/ |
| H A D | sched-bwc.rst | 13 Este documento únicamente trata el control de ancho de banda de CPUs
17 permite especificar el máximo uso disponible de CPU para un grupo o una jerarquía.
27 no serán capaces de ejecutarse de nuevo hasta el siguiente periodo cuando
41 devolver, con el coste de una mayor interferencia hacia los otros usuarios
49 y que el sistema es estable. De todas formas, si U fuese > 1, entonces
51 ejecutar más de un segundo y obviamente no se cumpliría con el tiempo
52 límite de ejecución de la tarea, pero en el siguiente periodo de ejecución
53 el tiempo límite de la tarea estaría todavía más lejos, y nunca se tendría
56 La característica de ráfaga implica que el trabajo de una tarea no siempre
60 Por ejemplo, se tiene u_i = {x,e}_i, donde x es el p(95) y x+e p(100)
[all …]
|
| 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
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
55 y por tanto es muy sencilla: siempre intenta ejecutar la tarea con el valor
[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 …]
|