Lines Matching full:en

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.
19 algunas de las maneras en que los desarrolladores del kernel pueden cometer
21 herramientas que pueden ayudar en dicha búsqueda.
30 estándar, descrito en la documentación del kernel en
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.
47 Ocasionalmente, el estilo de programación del kernel entrará en conflicto
48 con el estilo obligatorio de un empleador. En tales casos, el estilo del
50 Incluir código en el kernel significa renunciar a cierto grado de control
51 de varias maneras, incluida la forma en que se formatea el código.
53 La otra trampa es asumir que el código que ya está en el kernel necesita
56 familiarizarse con el proceso o como una forma de incluir su nombre en los
61 parte del código mientras se trabaja en él por otras razones, pero los
65 absoluta que nunca puede transgredirse. Si hay una buena razón para ir en
69 Tenga en cuenta que también puedes usar la herramienta `clang-format` para
86 hacer un uso extensivo de capas de abstracción en nombre de la
92 usarse en la medida necesaria y ya.
103 utilizados; en general, no deberían añadirse en primer lugar.
108 el código y pueden imponer una penalización en el rendimiento; no
113 sentido extraer parte de ese código en una biblioteca separada o
115 replicar el mismo código en todo el kernel.
117 Uso de #ifdef y del preprocesador en general
122 eficientemente una gran cantidad de flexibilidad en un archivo fuente. Pero
133 que, si el código no va a estar presente, simplemente se convierten en
141 considera crear una función en línea en su lugar. El código resultante será
142 el mismo, pero las funciones en línea son más fáciles de leer, no evalúan
144 comprobaciones de tipo en los argumentos y el valor de retorno.
146 Funciones en línea
149 Las funciones en línea presentan su propio peligro, sin embargo. Los
151 llamada a función y llenar un archivo fuente con funciones en línea. Esas
152 funciones, sin embargo, pueden en realidad reducir el rendimiento. Dado que
153 su código se replica en cada sitio de llamada, terminan hinchando el tamaño
154 del kernel compilado. Eso, a su vez, crea presión en las cachés de memoria
156 Las funciones en línea, como regla, deben ser bastante pequeñas y
158 es tan alto; la creación de un gran número de funciones en línea es un
161 En general, los programadores del kernel ignoran los efectos de caché bajo
162 su propio riesgo. El clásico intercambio de tiempo/espacio que se enseña en
164 hardware contemporáneo. El espacio *es* tiempo, en el sentido de que un
168 decidir si una función dada debe realmente ser en línea o no. Por lo tanto,
175 En mayo de 2006, la pila de red "Devicescape" fue, con gran fanfarria,
176 lanzada bajo la licencia GPL y puesta a disposición para su inclusión en el
178 redes inalámbricas en Linux se consideraba, en el mejor de los casos,
180 situación. Sin embargo, este código no fue incluido en el kernel principal
184 cerradas en una empresa. Pero un problema importante en particular fue que
185 no estaba diseñado para funcionar en sistemas multiprocesador. Antes de que
187 implementar un esquema de bloqueo en ella.
189 Hubo un tiempo en que se podía desarrollar código para el kernel de Linux
190 sin pensar en los problemas de concurrencia que presentan los sistemas
191 multiprocesador. Ahora, sin embargo, este documento se está escribiendo en
192 una computadora portátil con dos núcleos. Incluso en sistemas de un solo
194 respuesta aumentará el nivel de concurrencia dentro del kernel. Los días en
195 que se podía escribir código para el kernel sin pensar en el bloqueo han
200 por un bloqueo. El nuevo código debe escribirse teniendo en cuenta este
206 difícil para ser incluido en el kernel principal.
214 "regresión", y las regresiones se han vuelto muy mal recibidas en el kernel
222 que rompe? La mejor respuesta a esta pregunta fue expresada por Linus en
234 en la ABI del espacio de usuario. Una vez que se ha exportado una interfaz
248 de que nuestro código se integre en el kernel principal. Con ese fin, los
264 Tenga en cuenta que no todas las advertencias del compilador están
269 funciones de depuración; la mayoría de estas se encuentran en el submenú
271 cualquier kernel utilizado para desarrollo o pruebas. En particular,
285  - DEBUG_SLAB puede encontrar una variedad de errores en la asignación y
286    uso de memoria; debe usarse en la mayoría de los kernels de desarrollo.
293 en el rendimiento y no deben usarse todo el tiempo. Pero dedicar tiempo a
295 veces en poco tiempo.
299 liberación de cada bloqueo (spinlock o mutex) en el sistema, el orden en
300 que se adquieren los bloqueos en relación entre sí, el entorno actual de
302 adquieran en el mismo orden, que las mismas suposiciones de interrupción se
303 apliquen en todas las situaciones, y así sucesivamente. En otras palabras,
304 lockdep puede encontrar varios escenarios en los que el sistema podría, en
306 (tanto para desarrolladores como para usuarios) en un sistema desplegado;
314 fallos resultantes probablemente no hayan sido probadas en absoluto. El
316 confianza en su código si todas esas rutas de manejo de errores se hubieran
334 Sparse debe instalarse por separado (puede encontrarse en
336 empaqueta); luego, puede ejecutarse en el código agregando "C=1" a su
342 para el kernel se han empaquetado en el directorio scripts/coccinelle;
352 encontrar en
365 notificarle de un problema en su código a través de un "oportuno"
366 comentario en la lista de correo o, peor aún, el código problemático podría
367 ser eliminado. Es mucho más fácil usar estas herramientas en primer lugar.
372 La documentación a menudo ha sido más la excepción que la regla en el
374 facilitar la integración de nuevo código en el kernel, hará la vida más
375 fácil a otros desarrolladores, y será útil para sus usuarios. En muchos
381 esolviendo, la forma de la solución, las personas que trabajaron en el
382 parche, cualquier efecto relevante en el rendimiento, y cualquier otra cosa
409 para las funciones disponibles externamente. Incluso en áreas que no han
410 sido tan documentadas, no hay ningún inconveniente en agregar comentarios
414 kerneldoc, se puede encontrar en
419 Una vez más, las expectativas para el nuevo código son más altas que en el
421 poco deseo de tener código excesivamente comentado. El código en sí debe
427 explicarse en algún lugar. Las estructuras de datos importantes en general
434 Cambios en la API interna
438 puede romper, excepto en las circunstancias más graves. Las interfaces de
439 programación internas del kernel, en cambio, son altamente fluidas y pueden
446 Hay, por supuesto, algunas condiciones. Los cambios en la API se pueden
448 que realice un cambio en la API interna debe ir acompañado de una
450 cambio también debe desglosarse en un parche separado, en lugar de estar
457 miles de cambios, muchos de los cuales probablemente entren en conflicto
460 de que la justificación sea sólida. Tenga en cuenta que la herramienta
463 Cuando se realice un cambio incompatible en la API, siempre que sea
466 encontrado todos los usos en el árbol de esa interfaz. También alertará a