Lines Matching refs:en
8 Cómo participar en el desarrollo del kernel de Linux
12 sobre cómo convertirse en desarrollador del kernel de Linux y explica cómo
13 trabajar con el y en su desarrollo. El documento no tratará ningún aspecto
17 Si algo en este documento quedara obsoleto, envíe parches al maintainer de
18 este archivo, que se encuentra en la parte superior del documento.
22 ¿De modo que quiere descubrir como convertirse en un/a desarrollador/a del
24 Linux para este dispositivo." El objetivo de este documento en enseñarle
28 de la forma en que lo hace.
30 El kernel esta principalmente escrito en C, con algunas partes que son
31 dependientes de la arquitectura en ensamblador. Un buen conocimiento de C
32 es necesario para desarrollar en el kernel. Lenguaje ensamblador (en
35 sustituto para una educación sólida en C y/o años de experiencia, los
44 no aparecen en dicho estándar. El kernel usa un C independiente de entorno,
56 largo del tiempo en función de lo que se ha encontrado que funciona mejor
60 la forma de hacer las cosas en su empresa.
65 favor, revise el archivo COPYING, presente en la carpeta principal del
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
69 confiar en sus opiniones en materia legal.
81 cómo usar la función. Cuando un cambio en el kernel hace que la interfaz
83 información o un parche en las páginas del manual que expliquen el cambio
86 Esta es la lista de archivos que están en el código fuente del kernel y son
92 kernel. Quienes sean nuevos en el kernel deben comenzar aquí.
107 Este archivo describe en gran detalle cómo crear con éxito y enviar un
115 sujetos a escrutinio de contenido y estilo), pero en caso de no seguir
139 Si cree que ha encontrado un problema de seguridad en el kernel de
146 lectura importante para cualquier persona nueva en el desarrollo del
153 del kernel estable, y qué hacer si desea obtener un cambio en una de
168 completa de la API en el kernel y reglas sobre cómo manejar cerrojos
178 Los documentos que utilizan el markup ReST se generarán en
179 Documentation/output. También se pueden generar en formatos LaTeX y ePub
185 Convertirse en un/a desarrollador/a de kernel
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
215 para incluir su parche en el árbol del kernel de Linux, y posiblemente
216 descubrir en la dirección en que trabajar a continuación, si no tiene ya
220 Linux, es imperativo entender cómo funciona el código en cuestión. Para
225 fuente en un formato de página web indexada y autorreferencial. Una
227 encontrar en:
246 El mainline tree es mantenido por Linus Torvalds, y puede encontrarse en
247 https://kernel.org o en su repo. El proceso de desarrollo es el siguiente:
252 han incluido en el linux-next durante unas semanas. La forma preferida
255 en https://git-scm.com/), pero los parches simples también son validos.
257 en hacer el kernel nuevo lo más estable ("solido") posible. La mayoría
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
268 actual esta en un estado razonablemente sano y adecuado para la prueba.
273 Vale la pena mencionar lo que Andrew Morton escribió en las listas de
285 Cada lanzamiento en una gran serie estable incrementa la tercera parte de
289 estable más reciente del kernel, y no están interesados en ayudar a probar
290 versiones en desarrollo/experimentales.
296 problema relacionado con la seguridad, en cambio, puede causar un
300 en el árbol del kernel documenta qué tipos de cambios son aceptables para
307 desarrollo en repositorios fuente. De esta manera, otros pueden ver lo que
308 está sucediendo en las diferentes áreas del kernel. En áreas donde el
310 envíos en tal árbol del subsistema del kernel, para evitar conflictos entre
311 este y otros trabajos ya en curso.
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/.
319 es sujeto a revisión, que ocurre principalmente en las listas de correo
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
334 un repositorio especial de pruebas en el que se encuentran casi todos los
340 espera que entre en el kernel principal en el próximo período de "merge"
342 linux-next en ejecución.
347 El archivo 'Documentación/admin-guide/reporting-issues.rst' en el
355 Una de las mejores formas de poner en práctica sus habilidades de hacking
363 Para trabajar en informes de errores ya reportados, busque un subsistema
366 vez un rastreador de errores (bugtracker). Busque en los archivos de dicho
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
379 pueden encontrar en:
383 Existen archivos de la lista de correo en la web en muchos lugares
389 Es muy recomendable que busque en los archivos sobre el tema que desea
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.
398 Muchas de las listas están alojadas en kernel.org. La información sobre
399 estas puede ser encontrada en:
417 mantenga las líneas "El hacker John Kernel escribió ...:" en la parte
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
423 formato como se indica en :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`.
438 posible. Cuando envíe un parche para su aceptación, se revisará en sus
447 Recuerde, esto es parte de introducir su parche en el kernel. Tiene que ser
471 los problemas planteados en su parche, y envié otra vez.
477 entornos de desarrollo tradicionales en empresas. Aquí hay una lista de
485 - "Lo he testeado en 5 arquitecturas distintas..."
487 - "Esto mejora el rendimiento en maquinas típicas..."
491 - "Lo hicimos así en AIX/ptx/Solaris, de modo que debe ser bueno..."
496 - "Llevo 6 meses trabajando en esto..."
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
508 nivelar el campo de juego porque no puede adivinar el género basado en
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.
524 discutidos y divididos en pequeñas porciones individuales. Esto es casi
526 Su propuesta también debe introducirse muy temprano en el proceso de
539 puede tardar horas en ser revisado en términos de corrección (el tiempo
552 *"Piense en un maestro que califica la tarea de un estudiante de
565 Por lo tanto, es bueno comenzar temprano en el proceso para obtener
566 "feedback" y mejorar su trabajo, pero también mantenga sus cambios en
568 está listo para inclusión en un momento dado.
570 También tenga en cuenta que no es aceptable enviar parches para su
583 Cuando envíe sus parches, preste especial atención a lo que dice en el
584 texto de su correo electrónico. Esta información se convertirá en el
608 se basara en el texto que había escrito (https://lwn.net/Articles/94386/),