| /linux-6.15/fs/ocfs2/ |
| H A D | alloc.c | 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() 1091 ocfs2_rec_clusters(el, &el->l_recs[i]); in ocfs2_sum_rightmost_rec() 1641 el->l_recs[i] = el->l_recs[i+1]; in ocfs2_rotate_leaf() 2083 el = left_path->p_node[i].el; in ocfs2_complete_edge_insert() 2087 el = right_path->p_node[i].el; in ocfs2_complete_edge_insert() 2108 el = left_path->p_node[subtree_index].el; in ocfs2_complete_edge_insert() 2239 el = path->p_node[i].el; in ocfs2_find_cpos_for_left_leaf() 2563 el = path->p_node[i].el; in ocfs2_update_edge_lengths() 2837 el = path->p_node[i].el; in ocfs2_find_cpos_for_right_leaf() [all …]
|
| H A D | extent_map.c | 290 el = &eb->h_list; in ocfs2_last_eb_is_empty() 292 if (el->l_tree_depth) { in ocfs2_last_eb_is_empty() 323 rec = &el->l_recs[i]; in ocfs2_search_for_hole_index() 374 el = &next_eb->h_list; in ocfs2_figure_hole_clusters() 414 el = &di->id2.i_list; in ocfs2_get_clusters_nocache() 426 el = &eb->h_list; in ocfs2_get_clusters_nocache() 438 if (le16_to_cpu(el->l_next_free_rec) > le16_to_cpu(el->l_count)) { in ocfs2_get_clusters_nocache() 457 el, eb_bh, in ocfs2_get_clusters_nocache() 469 rec = &el->l_recs[i]; in ocfs2_get_clusters_nocache() 560 el = &eb->h_list; in ocfs2_xattr_get_clusters() [all …]
|
| /linux-6.15/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() 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() 97 KUNIT_ASSERT_LE_MSG(test, el->serial, el1->serial, in list_sort_test() [all …]
|
| /linux-6.15/Documentation/translations/sp_SP/process/ |
| H A D | 5.Posting.rst | 76 encuentra en el árbol git de Linus. Al basarse en el mainline, comience 113 correctamente; si su serie de parches se interrumpe en el medio, el 131 ultimo parche como el que causó el problema, aunque el error real esté 171 Los elementos de arriba, juntos, forman el registro de cambios para el 189 corrige un error, cita el commit que introdujo el error si es posible (y 190 por favor, proporcione tanto el ID del commit como el título al citar 210 editor) en el parche. El archivo “dontdiff” en el directorio de 215 información sobre cómo surgió el parche. Se describen en detalle en el 256 o ella tiene el derecho de enviar el parche para su inclusión en el 277 - Reviewed-by: el desarrollador nombrado ha revisado el parche para [all …]
|
| H A D | 1.Intro.rst | 23 :ref:`sp_development_process` introduce el proceso de desarrollo, el ciclo 73 Con el crecimiento de Linux, ha llegado un aumento en el número de 117 necesita desarrolladores que ayudan a mejorar el kernel; el siguiente 133 Importancia de integrar el código en el mainline 138 kernel y obtener su código en el kernel mainline (el “mainline” es el 156 el desarrollador y para el usuario. La incorporación al mainline 170 En su lugar, el código en el mainline no requiere este trabajo como 176 - Más allá de eso, el código que está en el kernel a menudo será 259 producto rápidamente para el mercado. 274 código aportado al kernel. Todo el código fusionado en el kernel [all …]
|
| H A D | 2.Process.rst | 60 el primero de los kernels “rc”. Para el kernel destinado a ser 5.6, por 63 características ha pasado y que el tiempo para estabilizar el siguiente 109 conocidas antes de que se realice el lanzamiento estable. En el mundo 112 retrasar el lanzamiento final solo empeora el problema; la pila de cambios 187 que el parche llegara hasta el mainline. El parche aparecerá en el 247 el kernel mainline. 284 La cadena de árboles de subsistemas guía el flujo de parches en el 365 staging no es el final de la historia; el código que no está viendo 368 Por lo tanto, el staging es, en el mejor de los casos, una parada en el 374 Como se puede ver en el texto anterior, el proceso de desarrollo del [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 48 con el estilo obligatorio de un empleador. En tales casos, el estilo del 53 La otra trampa es asumir que el código que ya está en el kernel necesita 87 flexibilidad y el ocultamiento de la información. Sin duda, el kernel hace 108 el código y pueden imponer una penalización en el rendimiento; no 115 replicar el mismo código en todo el kernel. 123 el preprocesador no es C, y el uso intensivo de él da como resultado un 201 requisito; implementar el bloqueo después de que el código ya ha sido 342 para el kernel se han empaquetado en el directorio scripts/coccinelle; [all …]
|
| H A D | handling-regressions.rst | 31 #. Haga que el bot del kernel de Linux "regzbot" realice el seguimiento del 38 el incidente:: 87 inmediatamente iniciar el seguimiento de la regresión con "regzbot" el 97 Esto indica a regzbot el rango de versiones en el cual es defecto 99 de los commits así como un único commit, en caso en el que el informante 103 Esto indica a regzbot, que debe tratar el email padre (el que ha sido 262 el cambio en el radar, en el caso de que aparezcan reportes. Dependiendo 308 Thorsten desarrollo regbot para facilitar el trabajo, con el objetivo a 521 el problema, entonces ha de ser el kernel el que lo corrija, porque 609 Así que claramente cambia el comportamiento todo el tiempo y [all …]
|
| H A D | submitting-patches.rst | 47 preparados para esos árboles. Revise el campo **T:** para el subsistema 62 Describa el impacto relativo al usuario. Cosas que estropeen el kernel y 85 lenguaje sencillo para que el revisor verifique que el código se está 222 en que lo mueve. Esto divide claramente el acto de mover el código y sus 267 Linus Torvalds es el árbitro final de todos los cambios aceptados en el 374 A: Porque desordena el orden en el que la gente normalmente lee el texto. 509 Acked-by: no necesariamente indica el reconocimiento de todo el parche. 512 indica el reconocimiento de solo la parte que afecta el código de ese 585 el kernel principal. 659 el autor). [all …]
|
| H A D | deprecated.rst | 68 De todos modos, el método recomendado en estos caso es reescribir el código 138 en el el valor retornado por strcpy() sea usado, ya que strscpy() no 139 devuelve un puntero a el destino, sino el número de caracteres no nulos 162 debería usarse strtomem(), y el destino debería señalarse con el atributo 171 strlcpy() primero lee por completo el buffer de origen (ya que el valor 172 devuelto intenta ser el mismo que el de strlen()). Esta lectura puede 182 Tradicionalmente,el uso de "%p" en el formato de cadenas de caracteres 188 mejor, ya que resulta en el nombre del símbolo. Para prácticamente el 193 - Si el valor "hasheado" "%p" no tienen ninguna finalidad, preguntarse si el 283 sizeof() (el cual hubiera necesitado eliminar el tamaño del último elemento [all …]
|
| H A D | embargoed-hardware-issues.rst | 35 en el kernel de Linux no son manejados por este equipo y el "reportero" 47 PGP del reportero o el certificado de S/MIME. La llave de PGP y el 106 dedicado para el contacto inicial, el cual supervisa el proceso de manejo 119 Además, el equipo de seguridad de hardware también excluirá al 154 inicialmente sobre el problema después de confirmar con los 176 que deben participar en el desarrollo de la mitigación. 202 varios problemas de seguridad de hardware en el pasado. 231 revelado por el equipo de incidente y se incorpora al proceso de 254 Ni el equipo de seguridad de hardware ni el equipo de respuesta inicial 264 orientación sobre el proceso de reporte y el manejo posterior. Los [all …]
|
| H A D | email-clients.rst | 22 envíe el parche a la(s) lista(s) de correo apropiada(s). 98 Al redactar el mensaje, el cursor debe colocarse donde el parche debería 100 archivo de parche a insertar en el mensaje. 126 para insertar el parche. 174 lugar de como texto en línea, haga clic con el botón derecho en el archivo 212 Si utiliza xclip, escriba el comando:: 220 si desea incluir el parche en línea. 287 - Permite el uso de un editor externo. 303 - Permitir el uso de un editor externo: 327 luego simplemente haga clic en el botón nuevo cuando desee usar el editor [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 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 112 A medida que el mainline (u otro árbol en el que se basa un conjunto de 125 que hacer el mismo trabajo dos veces. 150 adecuado, solicite que el árbol se incluya en linux-next. 170 aprender a programar en el entorno del kernel que mirando el código 181 el bloqueo en este camino?” siempre funcionará mejor que decir “el 194 enfocarán principalmente en si el cambio implementado por el parche en su [all …]
|
| H A D | 3.Early-stage.rst | 18 Especificar el problema 54 Siendo el texto original: 73 - ¿Cuál es exactamente el problema que necesita ser resuelto? 90 - Es posible que el problema ya esté siendo abordado por el kernel de 98 en el kernel principal. 102 como este antes de escribir el código. 147 desarrolladores con experiencia en el subsistema relevante y el ambiente 164 script para facilitar el proceso: 190 desarrollo a ofrecer comentarios útiles sobre el proyecto. 200 los desarrolladores del kernel prefieren ver el código. [all …]
|
| H A D | howto.rst | 8 Cómo participar en el desarrollo del kernel de Linux 15 guiándole por el camino correcto. 25 todo cuanto necesita para conseguir esto, describiendo el proceso por el 104 revisan el código si tiene el estilo adecuado. 189 el proyecto Linux KernelNewbies: 224 es el proyecto Linux Cross-Reference, que es capaz de presentar el código 301 el árbol estable y cómo funciona el proceso de lanzamiento. 340 espera que entre en el kernel principal en el próximo período de "merge" 452 pierden dado el gran volumen. 508 nivelar el campo de juego porque no puede adivinar el género basado en [all …]
|
| H A D | adding-syscalls.rst | 21 son los puntos de interacción entre el userspace y el kernel más obvios y 65 Diseñando el API: Planeando para extensiones 122 Diseñando el API: Otras consideraciones 158 Esto permite más flexibilidad en como el userspace especifica el archivo en 168 mire el man page :manpage:`fstatat(2)` manpage.) 198 Proponiendo el API 215 para el repositorio man-pages. 517 instalado para compilar el test. 537 en el cover del email para el patchset, para la conveniencia de los 544 No invoque las llamadas de sistemas en el kernel [all …]
|
| H A D | maintainer-kvm-x86.rst | 29 x86 está dividido entre el árbol principal de KVM, 35 para el siguiente ciclo se dirige a través del árbol de KVM x86. En el 41 tiempo, es decir, que será el statu quo en un futuro previsible. 62 decir, no pasan por el árbol x86 de KVM. 155 y/o para explicar por qué el código hace lo que hace. No reitere lo que el 156 código hace literalmente; deje que el código hable por sí mismo. Si el 256 inútiles, los detalles sólo importan para el culpable. Proporcionar el "qué 263 Si tanto "qué está cambiando" como "cuál es el fallo" son muy breves, el 315 verifique que el *exactamente el mismo* fallo se produce con y sin sus 412 repositorio utiliza para rastrear el remoto KVM x86. [all …]
|
| H A D | coding-style.rst | 11 Este es un breve documento que describe el estilo preferido en el código 335 Codificar el tipo de una función en el nombre (lo llamado notación húngara) 552 Elija nombres de etiquetas que digan qué hace el goto o por qué existe el 621 comentario: es mucho mejor escribir el código para que el 867 leerán el código. 907 en el kernel. 981 Ambos casos verifican el desbordamiento en el tamaño de asignación n * 1014 mantenimiento de eliminar el inline, cuando un segundo usuario supera el 1070 No use bool si el diseño de la línea de caché o el tamaño del valor son 1215 enfoque todavía permite que el compilador de C vea el código dentro del [all …]
|
| H A D | security-bugs.rst | 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 63 junto con la solución o en cualquier otro canal de divulgación sin el 71 que se haya levantado el embargo, en perpetuidad. 78 de correo “linux-distros” hasta DESPUES de discutirlo con el equipo de 92 correcciones, ya que esto puede complicar innecesariamente el proceso y [all …]
|
| /linux-6.15/fs/gfs2/ |
| H A D | xattr.c | 193 el->el_bh = bh; in ea_find_i() 212 ef.ef_el = el; in gfs2_ea_find() 550 if (!el.el_ea) in gfs2_xattr_acl_get() 596 if (!el.el_ea) in __gfs2_xattr_get() 1061 es.es_el = el; in ea_set_i() 1080 if (el->el_prev && GFS2_EA2NEXT(el->el_prev) != el->el_ea) { in ea_set_remove_unstuffed() 1081 el->el_prev = GFS2_EA2NEXT(el->el_prev); in ea_set_remove_unstuffed() 1083 GFS2_EA2NEXT(el->el_prev) == el->el_ea); in ea_set_remove_unstuffed() 1086 return ea_remove_unstuffed(ip, el->el_bh, el->el_ea, el->el_prev, 0); in ea_set_remove_unstuffed() 1145 if (!el.el_ea) in gfs2_xattr_remove() [all …]
|
| /linux-6.15/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)) ... 98 atomic_set(&el->rc, 1); atomic_inc(&el->rc); 110 kfree(el); ... 151 if (atomic_dec_and_test(&el->rc)) [all …]
|
| /linux-6.15/Documentation/translations/sp_SP/scheduler/ |
| H A D | sched-bwc.rst | 13 Este documento únicamente trata el control de ancho de banda de CPUs 64 tareas en el sistema), pero al coste de perder el instante límite de 80 Al mismo tiempo, se puede decir que el peor caso de sobrepasar el 82 (asumiendo que x+e es de hecho el WCET). 85 de fallar en el cumplimiento del tiempo límite y el promedio de WCET. 130 el límite con el ancho de banda acumulado no usado. 179 [ Donde C es el ancho de banda de el padre, y c_i el de su hijo ] 186 En el caso b) anterior, incluso si el hijo pudiera tener tiempo de 242 en los periodos siguientes cuando el sistema esté inactivo. 249 Si el periodo son 250ms y la cuota son 250ms el grupo de tareas tendrá el tiempo [all …]
|
| H A D | sched-design-CFS.rst | 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 77 CFS también mantiene el valor de rq->cfs.min_vruntime, el cual crece 85 contabilizado mediante el valor rq->cfs.load, el cual es la suma de los 99 que el tiempo de uso de la CPU se ha completado, y se añade a 122 SCHED_BATCH también es gestionado por el gestor de tareas CFS. 174 sched/fair.c implementa el gestor de tareas CFS descrito antes. 257 usando el pseudo sistema de archivos "cgroup" :: 267 # #Configurar el grupo multimedia para tener el doble de tiempo de CPU [all …]
|
| /linux-6.15/drivers/crypto/hisilicon/sec/ |
| H A D | sec_algs.c | 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() 380 kfree(el); in sec_alg_free_el() 640 el = kzalloc(sizeof(*el), gfp); in sec_alg_alloc_and_fill_el() 641 if (!el) in sec_alg_alloc_and_fill_el() 644 req = &el->req; in sec_alg_alloc_and_fill_el() 671 ret = sec_alloc_and_fill_hw_sgl(&el->in, &el->dma_in, el->sgl_in, in sec_alg_alloc_and_fill_el() 681 ret = sec_alloc_and_fill_hw_sgl(&el->out, &el->dma_out, in sec_alg_alloc_and_fill_el() 697 return el; in sec_alg_alloc_and_fill_el() 700 sec_free_hw_sgl(el->in, el->dma_in, info); in sec_alg_alloc_and_fill_el() [all …]
|
| /linux-6.15/Documentation/translations/sp_SP/ |
| H A D | memory-barriers.txt | 172 El conjunto de accesos visto por el sistema de memoria en el medio se puede 766 Peor aún, si el compilador puede probar (decir) que el valor de la 820 Por el contrario, sin barreras de memoria explícita, el control de un if 834 el valor de 'a'. 837 contrario, el compilador podría adivinar el valor y volver a eliminar el 1066 de memoria en un orden que el resto del sistema podría percibir como el 1816 Por supuesto, el compilador también debe respetar el orden en que 2169 con suceder, el RELEASE simplemente se completaría, evitando así el 2175 orden, no el compilador. Si el compilador (o, ya puestos, el 2500 el semáforo; [all …]
|