Lines Matching refs:de
8 Cómo participar en el desarrollo del kernel de Linux
11 Este documento es el principal punto de partida. Contiene instrucciones
12 sobre cómo convertirse en desarrollador del kernel de Linux y explica cómo
17 Si algo en este documento quedara obsoleto, envíe parches al maintainer de
23 kernel de Linux? Tal vez su jefe le haya dicho, "Escriba un driver de
24 Linux para este dispositivo." El objetivo de este documento en enseñarle
26 que debe pasar, y con indicaciones de como trabajar con la comunidad.
27 También trata de explicar las razones por las cuales la comunidad trabaja
28 de la forma en que lo hace.
31 dependientes de la arquitectura en ensamblador. Un buen conocimiento de C
34 desarrollo de bajo nivel para dicha arquitectura. Aunque no es un perfecto
35 sustituto para una educación sólida en C y/o años de experiencia, los
38 - "The C Programming Language" de Kernighan e Ritchie [Prentice Hall]
39 - "Practical C Programming" de Steve Oualline [O'Reilly]
40 - "C: A Reference Manual" de Harbison and Steele [Prentice Hall]
42 El kernel está escrito usando GNU C y la cadena de herramientas GNU. Si
43 bien se adhiere al estándar ISO C89, utiliza una serie de extensiones que
44 no aparecen en dicho estándar. El kernel usa un C independiente de entorno,
45 sin depender de la biblioteca C estándar, por lo que algunas partes del
46 estándar C no son compatibles. Divisiones de long long arbitrarios o
47 de coma flotante no son permitidas. En ocasiones, puede ser difícil de
48 entender las suposiciones que el kernel hace respecto a la cadena de
50 referencia definitiva para estas. Consulte las páginas de información de
53 Recuerde que está tratando de aprender a trabajar con una comunidad de
54 desarrollo existente. Es un grupo diverso de personas, con altos estándares
55 de código, estilo y procedimiento. Estas normas han sido creadas a lo
56 largo del tiempo en función de lo que se ha encontrado que funciona mejor
57 para un equipo tan grande y geográficamente disperso. Trate de aprender
58 tanto como le sea posible acerca de estos estándares antes de tiempo, ya
60 la forma de hacer las cosas en su empresa.
64 El código fuente del kernel de Linux se publica bajo licencia GPL. Por
66 código fuente, para detalles de la licencia. Si tiene alguna otra pregunta
67 sobre licencias, contacte a un abogado, no pregunte en listas de discusión
68 del kernel de Linux. La gente en estas listas no son abogadas, y no debe
77 El código fuente del kernel de Linux tiene una gran variedad de documentos
80 recomienda que se incluyan nuevos archivos de documentación que expliquen
82 que el kernel expone espacio de usuario cambie, se recomienda que envíe la
86 Esta es la lista de archivos que están en el código fuente del kernel y son
87 de obligada lectura:
90 Este archivo ofrece una breve descripción del kernel de Linux y
95 Este archivo proporciona una lista de los niveles mínimos de varios
100 Esto describe el estilo de código del kernel de Linux y algunas de los
101 razones detrás de esto. Se espera que todo el código nuevo siga las
102 directrices de este documento. La mayoría de los maintainers solo
115 sujetos a escrutinio de contenido y estilo), pero en caso de no seguir
117 Otras excelentes descripciones de cómo crear parches correctamente son:
126 Este archivo describe la lógica detrás de la decisión consciente de
130 - Portabilidad de drivers entre sistemas operativos
131 - Mitigar el cambio rápido dentro del árbol de fuentes del kernel (o
135 de Linux y es muy importante para las personas que se mudan a Linux
139 Si cree que ha encontrado un problema de seguridad en el kernel de
140 Linux, siga los pasos de este documento para ayudar a notificar a los
144 Este documento describe cómo operan los maintainers del kernel de Linux
145 y los valores compartidos detrás de sus metodologías. Esta es una
149 comunes sobre el comportamiento único de los maintainers del kernel.
153 del kernel estable, y qué hacer si desea obtener un cambio en una de
157 Una lista de documentación externa relativa al desarrollo del kernel.
159 dentro de la documentación del kernel.
163 aplicarlo a las diferentes ramas de desarrollo del kernel.
165 El kernel también tiene una gran cantidad de documentos que pueden ser
168 completa de la API en el kernel y reglas sobre cómo manejar cerrojos
185 Convertirse en un/a desarrollador/a de kernel
188 Si no sabe nada sobre el desarrollo del kernel de Linux, debería consultar
193 Consiste en una útil lista de correo donde puede preguntar casi cualquier
194 tipo de pregunta básica de desarrollo del kernel (asegúrese de buscar en
195 los archivos primero, antes de preguntar algo que ya ha sido respondido en
197 en tiempo real, y una gran cantidad de documentación útil para ir
198 aprendiendo sobre el desarrollo del kernel de Linux.
206 comenzar a hacer para unirse a la comunidad de desarrollo del kernel,
211 Es un gran lugar para comenzar. Describe una lista de problemas
213 fuente del kernel de Linux árbol de fuentes. Trabajando con los
214 desarrolladores a cargo de este proyecto, aprenderá los conceptos básicos
215 para incluir su parche en el árbol del kernel de Linux, y posiblemente
219 Antes de realizar cualquier modificación real al código del kernel de
222 está bien comentado), tal vez incluso con la ayuda de herramientas
223 especializadas. Una de esas herramientas que se recomienda especialmente
224 es el proyecto Linux Cross-Reference, que es capaz de presentar el código
225 fuente en un formato de página web indexada y autorreferencial. Una
231 El proceso de desarrollo
234 El proceso de desarrollo del kernel de Linux consiste actualmente de
236 a cada una de ellas. Las diferentes ramas son:
238 - El código principal de Linus (mainline tree)
247 https://kernel.org o en su repo. El proceso de desarrollo es el siguiente:
249 - Tan pronto como se lanza un nuevo kernel, se abre una ventana de dos
250 semanas, durante este período de tiempo, los maintainers pueden enviar
253 de enviar grandes cambios es usando git (la herramienta de
254 administración de código fuente del kernel, más información al respecto
256 - Después de dos semanas, se lanza un kernel -rc1 y la atención se centra
258 de los parches en este punto deben arreglar una regresión. Los errores
260 este tipo de correcciones si son importantes. Tenga en cuenta que se
261 podría aceptar un controlador (o sistema de archivos) completamente
262 nuevo después de -rc1 porque no hay riesgo de causar regresiones con
265 parches a Linus después de que se lance -rc1, pero los parches también
266 deben ser enviado a una lista de correo pública para su revisión.
271 puede durar alrededor de 6 semanas.
273 Vale la pena mencionar lo que Andrew Morton escribió en las listas de
274 correo del kernel de Linux, sobre lanzamientos del kernel (traducido):
277 según el estado de los bugs, no de una cronología preconcebida."*
282 Los kernels con versiones de 3 partes son kernels estables. Estos contienen
283 correcciones relativamente pequeñas y críticas para problemas de seguridad
284 o importantes regresiones descubiertas para una publicación de código.
285 Cada lanzamiento en una gran serie estable incrementa la tercera parte de
294 necesidades. El período de liberación normal es de aproximadamente dos
300 en el árbol del kernel documenta qué tipos de cambios son aceptables para
301 el árbol estable y cómo funciona el proceso de lanzamiento.
305 Los maintainers de los diversos subsistemas del kernel --- y también muchos
306 desarrolladores de subsistemas del kernel --- exponen su estado actual de
313 La mayoría de estos repositorios son árboles git, pero también hay otros
314 SCM en uso, o colas de parches que se publican como series quilt. Las
315 direcciones de estos repositorios de subsistemas se enumeran en el archivo
316 MAINTAINERS. Muchos de estos se pueden ver en https://git.kernel.org/.
318 Antes de que un parche propuesto se incluya con dicho árbol de subsistemas,
319 es sujeto a revisión, que ocurre principalmente en las listas de correo
322 ofrece una interfaz web que muestra publicaciones de parches, cualquier
324 marcar los parches como en revisión, aceptado, o rechazado. La mayoría de
325 estos sitios de trabajo de parches se enumeran en
332 Antes de que las actualizaciones de los árboles de subsistemas se combinen
334 un repositorio especial de pruebas en el que se encuentran casi todos los
335 árboles de subsistema, actualizado casi a diario:
339 De esta manera, linux-next ofrece una perspectiva resumida de lo que se
340 espera que entre en el kernel principal en el próximo período de "merge"
341 (fusión de código). Los testers aventureros son bienvenidos a probar
349 kernel y detalles sobre qué tipo de información necesitan los
352 Gestión de informes de bugs
355 Una de las mejores formas de poner en práctica sus habilidades de hacking
359 cuenta de tu presencia. La corrección de errores es una de las mejores
360 formas de ganar méritos entre desarrolladores, porque no a muchas personas
361 les gusta perder el tiempo arreglando los errores de otras personas.
363 Para trabajar en informes de errores ya reportados, busque un subsistema
365 errores de ese subsistema; con frecuencia será una lista de correo, rara
366 vez un rastreador de errores (bugtracker). Busque en los archivos de dicho
368 posible que desee revisar https://bugzilla.kernel.org para informes de
369 errores; solo un puñado de subsistemas del kernel lo emplean activamente
373 Listas de correo
376 Como se explica en algunos de los documentos anteriores, la mayoría de
377 desarrolladores del kernel participan en la lista de correo del kernel de
378 Linux. Detalles sobre cómo para suscribirse y darse de baja de la lista se
383 Existen archivos de la lista de correo en la web en muchos lugares
384 distintos. Utilice un motor de búsqueda para encontrar estos archivos. Por
390 tratar, antes de publicarlo en la lista. Un montón de cosas ya discutidas
391 en detalle solo se registran en los archivos de la lista de correo.
393 La mayoría de los subsistemas individuales del kernel también tienen sus
394 propias lista de correo donde hacen sus esfuerzos de desarrollo. Revise el
395 archivo MAINTAINERS para obtener referencias de lo que estas listas para
398 Muchas de las listas están alojadas en kernel.org. La información sobre
403 Recuerde mantener buenos hábitos de comportamiento al usar las listas.
409 Si varias personas responden a su correo, el CC (lista de destinatarios)
410 puede hacerse bastante grande. No elimine a nadie de la lista CC: sin una
411 buena razón, o no responda solo a la dirección de la lista. Acostúmbrese
412 a recibir correos dos veces, una del remitente y otra de la lista, y no
413 intente ajustar esto agregando encabezados de correo astutos, a la gente no
416 Recuerde mantener intacto el contexto y la atribución de sus respuestas,
418 superior de su respuesta, y agregue sus declaraciones entre las secciones
419 individuales citadas en lugar de escribiendo en la parte superior del
422 Si incluye parches en su correo, asegúrese de que sean texto legible sin
425 parches comprimidos; y pueden querer comentar líneas individuales de su
426 parche, que funciona sólo de esa manera. Asegúrese de emplear un programa
427 de correo que no altere los espacios ni los tabuladores. Una buena primera
429 propio parche. Si eso no funciona, arregle su programa de correo o
432 Sobretodo, recuerde de ser respetuoso con otros subscriptores.
437 El objetivo de la comunidad del kernel es proporcionar el mejor kernel
443 - peticiones de cambios
444 - peticiones de justificaciones
447 Recuerde, esto es parte de introducir su parche en el kernel. Tiene que ser
448 capaz de recibir críticas y comentarios sobre sus parches, evaluar
450 y conciso de por qué no se deben hacer tales cambios. Si no hay respuestas
451 a su publicación, espere unos días e intente de nuevo, a veces las cosas se
457 - actuar de forma defensiva
459 - enviar el parche de nuevo, sin haber aplicados los cambios pertinentes
469 de una docena de cosas que debe corregir. Esto **no** implica que su
476 La comunidad del kernel funciona de manera diferente a la mayoría de los
477 entornos de desarrollo tradicionales en empresas. Aquí hay una lista de
483 - "Esto elimina 2000 lineas de código."
486 - "Aquí hay una serie de parches menores que..."
491 - "Lo hicimos así en AIX/ptx/Solaris, de modo que debe ser bueno..."
492 - "Llevo haciendo esto 20 años, de modo que..."
494 - "Esto es para la linea de nuestros productos Enterprise"
495 - "Aquí esta el documento de 1000 paginas describiendo mi idea"
497 - "Aquí esta un parche de 5000 lineas que..."
501 Otra forma en que la comunidad del kernel es diferente a la mayoría de los
502 entornos de trabajo tradicionales en ingeniería de software, es la
503 naturaleza sin rostro de interacción. Una de las ventajas de utilizar el
504 correo electrónico y el IRC como formas principales de comunicación es la
505 no discriminación por motivos de género o raza. El entorno de trabajo del
506 kernel de Linux acepta a mujeres y minorías porque todo lo que eres es una
507 dirección de correo electrónico. El aspecto internacional también ayuda a
508 nivelar el campo de juego porque no puede adivinar el género basado en
509 el nombre de una persona. Un hombre puede llamarse Andrea y una mujer puede
510 llamarse Pat. La mayoría de las mujeres que han trabajado en el kernel de
515 necesario para transmitir ideas correctamente en las listas de correo, por
517 de que tengan sentido en inglés antes de enviarlos.
522 La comunidad del kernel de Linux no acepta con gusto grandes fragmentos de
525 exactamente lo contrario de lo que las empresas están acostumbradas a hacer.
526 Su propuesta también debe introducirse muy temprano en el proceso de
527 desarrollo, de modo que pueda recibir comentarios sobre lo que está
530 embargo, no envíe 50 correos electrónicos a una vez a una lista de correo,
531 su serie de parches debe casi siempre ser más pequeña que eso.
535 1) Los cambios pequeños aumentan la probabilidad de que sus parches sean
537 exactitud. Un parche de 5 líneas puede ser aplicado por un maintainer
538 con apenas una segunda mirada. Sin embargo, un parche de 500 líneas
539 puede tardar horas en ser revisado en términos de corrección (el tiempo
545 parche muy grande después de haber sido aplicado (y roto alguna cosa).
548 y simplificar (o simplemente reordenar) los parches antes de enviarlos.
552 *"Piense en un maestro que califica la tarea de un estudiante de
554 estudiante antes de que se les ocurriera la solución. Quiere ver la
556 presentaría su trabajo intermedio antes de tener la solución final.*
559 revisores no quieren ver el proceso de pensamiento detrás de la solución
576 Además de dividir sus parches, es muy importante que deje a la comunidad de
584 texto de su correo electrónico. Esta información se convertirá en el
589 - el diseño general de su propuesta
590 - detalles de implementación
591 - resultados de sus experimentos
599 Todas estas cuestiones son a veces son muy difíciles de conseguir. Puede
601 continuo de mejora que requiere mucha paciencia y determinación. Pero no se
609 y a Randy Dunlap y Gerrit Huizenga por algunas de la lista de cosas que