Respuestas a preguntas frecuentes de la lista de correo del linux kernel

Respuestas a Preguntas Frecuentes de la lista de correo del linux kernel

Antes de considerar postear a la lista de correo del linux kernel, por favor por lo menos lea el inicio de la Sección 3 de esta lista de preguntas frecuentes.

Estas respuestas a preguntas frecuentes se divididen en varias categorís. Por favor aporte a alguna categoría y Pregute/Responda a lo que pueda encontrar relevante. También puedes añadir tu respuesta a alguna pregunta que ya haya sido respondida, Si tienes información adicional para contribuir.

El sitio oficial es: http://www.tux.org/lkml/ (Esto es en la costa este en los EUA). Muchas gracias a Sam Chessman y a David Niemi por el hosting de las FAQ en banda-ancha, en un servidor linux que se maneja profesionalmente. Se encuentran disponibles los siguientes mirrors (los cuales se actualizan al mismo tiempo que el servidor principal):

Hot off the Presses

vger.kernel.org ha habilitado ECN. Es posible que necesites cambiar de ISP para recibir correo de la lista de correo del linux kernel. Mira la sección ECN para más detalles.

Existen dos formas de entrega de la lista del linux-kernel (una entrega normal cada 100KB y una entrega diaria una vez al día) estan disponibles en http://lists.us.dell.com/.

Vaya a http://www.atnf.csiro.au/~rgooch/linux/docs/kernel-newsflash.html para noticias acerca de lanzamientos oficiales del kernel.

Lee esto antes de enviar quejas a la LKML acerca de problemas de compilación. Las oportunidades son cientos de personas que se han dado cuenta del problema y lo han solucionado y ya lo han publicado.

Indice

Documentación básica acerca del linux kernel

Los siguientes son vinculos relacionados con el Linux Kernel, los cuales deberias ojear antes de postear a la lista de LKML:

Contribuyentes y algunas expresiones especiales

Esta es una lista de los contribuyentes a estas FAQ. Estan listados en orden alfabetico de sus abreviaciones, usadas en la Sección de Respuestas para identificar al autor de cada respuesta(s). Algunas expresiones Inglesas para lectores ingleses no nativos. Muchas de ellas (y talvez más) pueden obtenerse en el Archivo Jargon:

Listas de correo relacionadas

Algunas preguntas se postean a las listas de correo con asuntos especiales. Posteando a esas listas de correo se reduce el volumen en la LKML e incrementa tu oportunidad de respuesta, de que tu mensaje sea leido por un experto en el tema. Algunas personas no tienen tiempo se suscribirise a la LKML, como También es muy general para ellos. Algunas listas relacionadas son:

Indice de Preguntas

Sección 1 - Preguntas generales

  1. Por que usan "GNU/Linux" y a veces solo "Linux" en otras partes de las FAQ?
  2. Qué es una versión experimental de kernel?
  3. Qué es un kernel de producción?
  4. Qué es feature freeze?
  5. Qué es código freeze?
  6. Qué es un kernel f.g.hhprei?
  7. Dónde consigo las ultimas fuentes del kernel?
  8. Dónde consigo parches extra para el kernel?
  9. Qué es un parche?
  10. Cómo hago que un parche sea adecuado para la lista de correo del linux kernel?
  11. Cómo aplico un parche?
  12. Todos hablan del "árbol CVS en vger". Qué es vger?
  13. Qué es un árbol CVS? Dónde puedo encontrar más información acerca de CVS?
  14. Hay un tutorial CVS?
  15. Cómo aplico mi parche en el kernel?
  16. Por qué el tarball del kernel contiene un directorio llamado linux/ en vez de linux-x.y.z/ ?
  17. Cuál es la diferencia entre los kernels oficiales y la serie de parches de Alan Cox's -ac ?
  18. Qué significa que un modulo va a ser corrupto (tainted)?
  19. Qué hay acerca de los símbolos GPLONLY ?
  20. Tengo que usar BitKeeper para enviar parches?
  21. Por qu&eeacute; algunos desarrolladores usan BitKeeper (no-libre) ? Va esto en contra del Software Libre?
  22. Quién mantiene el kernel?
  23. El kernel no compila limpiamente. Qué hago ?

Sección 2 - Preguntas especifícas acerca de drivers

  1. El driver tal y tal estan rotos!
  2. Aquí hay un nuevo driver para el hardware XYZ.
  3. Hay soporte para mi tarjeta TW-345 modelo C el kernel versión f.g.hh?
  4. Quién mantiene el driver tal y tal?
  5. Quiero escribir un driver para la tarjeta TW-345 modelo C, cómo comienzo?
  6. Quiero conseguir documentación, pero ellos quieren que firme un NDA (Non-Disclosure Agreement) (Acuerdo de No-descubrimiento).
  7. Quiero/necesito/debo tener un driver para la tarjeta TW-345 modelo C! Nadie lo escribira por mi?
  8. Qué es el número mayor/menor de un dispositivo?
  9. Por qué los WinModems no estan soportados?
  10. las CPUs modernas son muy rapidas, entonces por que no puedo escribir un manejador de interrupciones en modo usuario?
  11. Necesto probar mi driver en todas las distribuciones?

Sección 3 - Preguntas de la lista de correo

  1. Cómo me suscribo a la lista de correo del linux kernel?
  2. Cómo me de-suscribo de la lista de correo de la lista de correo del linux kernel?
  3. Debo estar suscrito a la lista de correo para postear?
  4. Hay algún archivo de la lista?
  5. Cómo puedo buscar en el archivo una pregunta en especial?
  6. Hay otras formas para buscar en la Web información acerca de algún asunto en particular del Linux kernel?
  7. Qué tan pesado es el tráfico de la lista de correo?
  8. Qué tipo de preguntas puedo hacer en la lista?
  9. Qué estilo de posteo debo utilizar en la lista?
  10. Es la lista moderada?
  11. Puedo ser expulsado de la lista?
  12. Hay alguna regla implicita en la lista de correo de la cual debo tener cuidado?
  13. Llega spam a la lista ?
  14. No recibi más mails de nadie más de la lista! Esta de baja de lista o que?
  15. Hay algún gateway NNTP en algún lado para la lista de correo?
  16. Quiero postear una gran idea (tm) a la lista. Qué debo hacer?
  17. Hay un largo hilo acerca de algo totalmente no relacionado con el kernel, y por eso algunas personas que estan en la Sección "Quién es quién" de estas FAQ estan mingling en ella. Qué debo hacer para evitar este "ruido" (noise)?
  18. Podemos modificar la línea Subject: para ayudar a los filtros de mail?
  19. Podemos tener un encabezado automaticamente Reply-To: añadido al tráfico de la lista?
  20. Puedo postear ofertas/pedidos de trabajo en la lista?
  21. Por qué obtengo rebotes (bounces) cuando envio mail privado a algunas personas?

Sección 4 - Preguntas "Cómo ?"

  1. Cómo posteo un parche?
  2. Cómo capturo un Oops?
  3. Cómo posteo un Oops?
  4. Creo que encontre un bug, cómo lo reporto?
  5. Qué información debo incluir en un reporte de bug?
  6. He encontrado un bug en una versión "antigua" del kernel, debo reportarlo?
  7. Cómo compilo el kernel?

Sección 5 - Preguntas "Quién es quién ?"

Los nombres se encuentran en orden alfabetico (apellido) para evitar caer de bruces.
Si alguien no aparece aquí, mira /usr/src/linux/CREDITS.
  1. Quién es el encargado aquí?
  2. Por qué no se tiene una página del Equipo del Linux Kernel, como la tienen otros projectos?
  3. Por qué nadie de los de abajo responde mis correos? Es esto difícil?
  4. Por qué obtengo rebotes (bounces) cuando envio mail privado a algunas personas?
  5. Quién es Matti Aarnio?
  6. Quién es H. Peter Anvin?
  7. Quién es Donald Becker?
  8. Quién es Alan Cox?
  9. Quién es Richard E. Gooch?
  10. Quién es Paul Gortmaker?
  11. Quién es Bill Hawes?
  12. Quién es Mark Lord?
  13. Quién es Larry McVoy?
  14. Quién es David S. Miller?
  15. Quién es Linus Torvalds?
  16. Quién es Theodore Y. T'so?
  17. Quién es Stephen Tweedie?
  18. Quién es Roger Wolff?
Algunas personas aún no han contribuido con unas pocas lineas de ellos mismos, y la politica de estas FAQ dice que nadie va a escribir acerca de nadie sin autorización. De aquí los vinculos rotos e.g. Si no eres Linus, no insistas, no vamos a incluir tu información sobre Linus.

Otros desarrolladores de SO's:

Sección 6 - Preguntas de CPU

Es esto un problema de tacto o que?
  1. Cuál es la "mejor" CPU para GNU/Linux?
  2. Cuál es la CPU más rapida para GNU/Linux?
  3. Quiero implementar el linux kernel para una CPU Hyper123, donde comienzo?
  4. Por qué el kernel detecta mi Cyrix 6x86/L/MX como un Cx486?
  5. Qué hay acerca de esos bugs de la CPU x86 leo acerca de ellos?
  6. He descargado el tarball del kernel de ftp.kernel.org o de algún mirror de este, y este no compila en SPARC, qué pasa?
  7. Ejecuta el Linux kernel la instrucción Halt para apagar la CPU?
  8. Tengo una CPU x86 no-Intel x86. Cuál es la [mejor|correcta] opción de configuración de kernel para mi CPU?
  9. En que tipo de CPU's corre Linux?

Sección 7 - Preguntas acerca del sistema operativo

Teoria acerca de SO'S y una mezcla práctica.
  1. SO $toomuch tiene esta agradable característica, por esto debe ser mejor que GNU/Linux.
  2. Por qué el linux kernel no tiene una pantalla de inicio gráfico como el SO $toomuch?
  3. El kernel en la variante CTE tiene esta característica muy-muy buena , puedo portarla al linux kernel?
  4. Qué hay acerca de agregar alguna buena característica al linux kernel?
  5. Hay más bugs en las versiones más recientes del Linux kernel, comparadas con versiones pasadas?
  6. Por qué el código del linux kernel, cada vez se hace más y más grande?
  7. Las fuentes del kernel son enormes y toma demasiado tiempo descargarlas. no puden dividirse en varios tarballs?
  8. Qué hay acerca de los terminos de licencia/copia en el linux kernel?
  9. Qué son todas esas referencias a la "catedral " y el "bazar"?
  10. Qué es "dominación mundial"?
  11. Cuáles son los futuros planes para el Linux kernel?
  12. Por que este muestra BogoMips en vez de MHz en el mensaje de arranque del kernel?
  13. Instale el kernel x.y.z y el paquete foo ya no funciono más, Qué puedo hacer?
  14. La gente habla acerca de espacio de usuario vs. espacio de kernel. Cuál es la ventaja de cada uno?
  15. Qué son hilos (threads)?
  16. Puedo usar hilos (threads) con GNU/Linux?
  17. Quieres decir que los hilos (threads) se implementan en espacio de usuario? Por que no en espacio de kernel? Por qué no seria más eficiente?
  18. Se puden hacer clusters con máquinas GNU/linux?
  19. Qué tan bien funciona Linux con SMP?
  20. Puedo cerrar (lock) un proceso/tarea en la CPU?
  21. Qué tan eficientes son los hilos (threads) bajo Linux?
  22. Cómo trabaja la pila (stack) de red/TCP en linux?
  23. Podemos poner la pila (stack) de red/TCP en espacio de usuario?

Sección 8 - Preguntas acerca del Compilador/binutils

Problemas en la compilación del Kernel.
  1. Descargué el ultimo kernel y no compila! Qué esta mal?
  2. Cuál es el compilador/binutils adecuado para compilar kernels?
  3. Por qué el compilador recomendado? Me gusta mejor el compilador xyz.
  4. Puedo compilar el kernel con gcc 2.8.x, egcs, (agrega tu compilador xyz aqí)? Qué hay acerca de las optimizaciones? Cómo puedo usar -O99, etc.?
  5. Compilé el kernel con un compilador xyz y me salen las siguientes advertencias/errores/comportamiento extraño, debo postear un reporte de bug a la lista? Debo postear un parche?
  6. Por qué la compilación de mi kernel se detiene en un punto alertorio con: "Internal compiler error: program cc1 caught fatal signal 11." ("Error interno del compilador: programa cc1 aplicó señal fatal 11")?
  7. Qué banderas del compilador debo usar para compilar modulos?
  8. Por qué me salen símbolos no resueltos como foo__ver_foo en los modulos?
  9. Por qué me salen símbolos no resueltos con el nombre __bad_ ?

Sección 9 - Preguntas acercas de características especiales

Preguntas miscelaneas acerca de las características del kernel.
  1. GNU/Linux Y2K compliance?
  2. Cuál es el tamaño máximo de un archivo soportado bajo ext2fs? 2 GB?
  3. Qué hay acerca de la controversia GGI/KGI O la interfaz de gráficos en espacio de Kernel?
  4. Cómo implemento más de 16 discos SCSI?
  5. Qué es el devfs y porque es Buena Idea (tm)?
  6. Administración de memoria en linux? Asignación de zonas?
  7. Cuántos archivos puedo tener abiertos simultaneamente?
  8. Cuándo se corregir´ el bug de Linux accept(2)?
  9. Qué hay acerca de STREAMS? Me he dado cuenta que caldera tiene un paquete de STREAMS, cuándo ira esto propiamente en las fuentes del kernel?
  10. Necesito encriptaci´n y steganography. Por quén no estan en el kernel?
  11. Qué hay de una fácilidad "undelete" en el kernel?
  12. Qué hay acerca del tmpfs para Linux?
  13. Cuál es el máximo tamaño de archivo/sistema de archivos?
  14. Linux usa mucho la swap mientras aún tengo cosas en cache. Esto no es malo?
  15. Por qué no se añade recursos forks/streams a los sistemas de archivos linux como los tiene NT?
  16. Por quén no se internacionaliza los mensajes del kernel?

Sección 10- Preguntas acerca de que ha cambiado entre kernels 2.0.x y 2.2.x"

  1. Tamaño (fuente y ejecutable)?
  2. Puedo usar un kernel 2.2.x con una distribución basada en un kernel 2.0.x?
  3. Nuevos sistemas de archivos?
  4. Rendimiento?
  5. Nuevos drivers no disponibles bajo los 2.0.x?
  6. Qué son esos macros __initxxx?
  7. He visto muchos posteos sobre el "Memory Rusting Effect" ("Efecto de Rostizamiento de Memoria"). Bajo que circunstancias/por qué ocurre esto?
  8. Por qué ifconfig muestra estadisticas con los kernels 2.2.x ?
  9. Mis dispositivos pseudo-tty no funcionan más. Qué paso?
  10. Puedo usar ptys Unix 98?
  11. Capacidades?
  12. Cambios en la API del Kernel?

Sección 11- Documentos Primarios

Por favor, Si deseas contribuir a PREGUNTAR/RESPONDER en esta Sección, Brinda una respuesta corta definiendo el tópico y entonces una URL un vínculo para un texto/página Web más largo. Cómo podemos tener varias URL's para una pregunta, cada una con diferente punto de vista. Otra ventaja de aprovechas es que cada contribuyente tiene que sentarse y escribir un página HTML coherente o archivo de texto. Que tenga una estructura la respuesta de un escritor es bastante amplia para pensar acerca de las ediciones y el tópico como un todo. Esto también permite revisiones independientes, lo cual seria imposible para las FAQ por sí mismas.

Notese que escribir un texto/página Web sobre algún tópico relevante sobre el linux kernel y dando la PREGUNTA/RESPUESTA te confiere el Estado de Guru . Algunas personas *matarian* por eso. Ahora ve y escribe lo tuyo! ;)

  1. Qué es un documento primario y por que debo leerlo primero?
  2. Qué hay acerca de tener puertos de complemento E/S?
  3. Qué es el VFS y cómo funciona?
  4. Cuál es la noción del tiempo del linux kernel?
  5. Hay algo mágico en /proc/scsi que pueda usarse para re-escanear el bus SCSI?

Sección 12 - Preguntas acerca de la Programación del Kernel

Respuestas acerca de detalles acerca del la programación del kernel. Mira También la página de Tigran Aivazian en Programación del kernel.
  1. Por qué se necesita cli()?
  2. Por qué aveces veo un par cli()-sti(), y a veces secuencias save_flags-cli()-restore_flags?
  3. Puedo llamar a printk() cuando las interrupciones esten deshabilitadas?
  4. Cuál es el propósito exacto de start_bh_atomic() y end_bh_atomic()?
  5. Es seguro arrebatar el cierre (lock) global del kernel multiples veces?
  6. Cuándo necesito inicializar variables?

Sección 13- Mensajes Misteriosos del Kernel

Cuándo a veces me salen esos mensajes en los logs de nuestro sistema y me gustaría saber que significan...
  1. Qué significa exactamente "Socket destroy delayed" ("Destrucción retardada de Sockets")?
  2. Qué hago con los "MTRRs inconsistentes"?
  3. Por qué mi kernel reporta muchos mensajes de "DriveStatusError BadCRC"?
  4. Por qué mi kernel reporta muchos mensajes de "APIC error"?

Sección 14 - Comportamiento extraño del kernel

El kernel se comporta de manera extraña...
  1. Por qué kapmd usa por mucho tiempo la CPU ?
  2. Por que el kernel 2.4 reporta Conección rechadaza Cuándo me conecto a sitios los cuales funcionaban bien con kernels previos?
  3. Por qué el kernel ahora reporta memoria compartida cero?
  4. Por qué lsmod reporta una cuenta de uso de -1 en algunos modulos? Es esto un bug?
  5. Por qué el kernel no reconoce toda mi RAM?
  6. He montado un sistema de archivos en dos lugares distintos y funcionó. Por qué?

Sección 15 - Religión de Programación

Respuestas acerca de sugerencias acerca de técnicas de programación y lenguajes.
  1. Por qué el linux kernel esta escrito en C/assembler?
  2. Por qué no rescribimos todo el linux kernel en assembler para el procesador Mega666?
  3. Por qué no reescribimos el linux kernel en C++?
  4. Qué es un kernel monolitico? Por qué no lo reescribimos como microkernel?
  5. Por qué no reemplazamos todos los goto's con excepciones de C ?
  6. Por qué los desarrolladores de kernel muestran rechazo hacia las nuevas técnicas?

Sección 16 - Preguntas acerca de Programación en espacio de usuario

Respuestas a preguntas comunes acerca de los detalles de la programación en espacio de usuario, como se relaciona esto con el espacio usuario/kernel (ej. llamadas de sistema). Esto no abarca preguntas acerca de la librería C, no con cualquier otra librería, por qué esas preguntas no estan relacionadas con el kernel.
  1. Por qué setsockopt() double SO_RCVBUF?

Respuestas

Sección 1 - Preguntas generales

  1. Por qué se usa a veces "GNU/Linux" y a veces solamente "Linux" en otras secciones de estas FAQ?
    • (ADB) En estas FAQ, hemos tratado de usar la palabra "Linux" o la expresion "Linux Kernel" para designar al kernel, y GNU/Linux para designar el cuerpo entero del software del SO que cumple con la licencia GNU/GPL, como se encuentra en muchas distribuciones. Preferimos llamar a un gato, gato, y a GNU, GNU. ;-)
      El proposito de estas FAQ es brindar información acerca del Linux Kernel rechazando debates e.j. ediciones de semantica. Discusiones más alla en la relación entre el software GNU y Linux puede encontrarse en http://www.gnu.org/gnu/linux-and-gnu.html.
      BTW, parece que mucha gente olvidó que la lista de correo del linux kernel es un foro para discusión relacionada con el kernel, no sobre GNU/Linux en general; por favor no pongas estos asuntos en la lista.
  2. Qué es una versión experimental de kernel?
    • (ADB)) Las versiones del Linux kernel estan dividas en dos series: experimental (series impares e.j. 1.3.xx o 2.1.x) y producción (series pares e.j. 1.2.xx, 2.0.xx, 2.2.x, 2.4.x y asi sucesivamente). Las series experimentales cambian más rapido de versiones las cuales se usan para probar nuevas características, algoritmos, drivers para dispositivos, etc. Por su propia naturaleza los kernel experimentales pueden comportarse de forma inpredecible, por eso puede haber perdida de datos, bloqueos aleatorios de la máquina, etc.
  3. Qué es un kernel de producción?
    • (ADB) Los kernels de producción o estables tiene un conjunto de características bien definidas, bajo reporte de bugs conocidos, y drivers probados y aprobados. Estos se lanzan con menos frecuencia que los kernels experimentales, por eso algunas "vintages" se consideran mejores que otras. Las distribuciones GNU/Linux se basan usualmente o han escogido versiones estables del kernel, no necesariamente la ultima versión de produccci&aocte;n.
  4. Qué es una característica freeze?
    • (ADB) Una característica freeze es cuando Linus anuncia en la lista de correo del kernel que no considerara más características hasta el próoximo lanzamiento de una nueva versión estable del kernel. Usualmente el efecto red del cual su anuncio cuando en los siguientes dias la gente en la lista propone una ráfaga de nuevas características antes de que Linus imponga la característica freeze. ;-)
  5. Qué es código freeze?
    • (ADB) Un código freeze es más restrictivo que una caracterísitica freeze; esto solo significa que se han aceptado muchos reparos a bugs. Este es un corto paso que usualmente precede la creación de un nuevo árbol de kernel estable.
  6. Qué es un kernel f.g.hhprei ?
    • (ADB) Estos son versiones de pre-lanzamiento intermedio de la versión f.g.hh. Note que usualmente i < 5, pero e.j. 2.0.34prei estuvo disponible con i = 1 a 16. A veces el "pre" se reemplaza por las iniciales del desarrollador poniendose junto a la revisión del kernel, e.j. 2.1.105ac4 significa la 4ta versión intermedia del kernel versión 2.1.105 por Alan Cox.
  7. Dónde consigo las ultimas fuentes del kernel?
    • (ADB) El sitio primario para las fuentes del Linux Kernel (experimental y producción) es hosted por Transmeta (la compañia para la cual trabaja Linus Torvalds) en un servidor Web dedicado servidor en http://www.kernel.org/. Este sitio tiene mirrors a través de todo el mundo, y tiene punteros a cada país. Puedes ir directamente al mirror de tu país yendo a http://www.CODE.kernel.org/ donde "CODE" es el código adecuado de país. Por ejemplo, "au" es el código de país para Australia, entonces el mirror principal para Australia es http://www.au.kernel.org/
    • (REG) También puedes accesar a los parches directamente vía ftp desde ftp://ftp.CODE.kernel.org/pub/linux/kernel/ es el cual es desde donde Linus distribuye sus kernels. Otros notables hackers del kernel tienen directorios bajo en el directorio people, el cual es donde ellos mantienen sus parches para kernel. El directorio testing puedes encontrar parches los cuales pueden estallar u originar corrupción del sistema de archivos. Usalos por tu propio riesgo.
  8. Dónde consigo parches extras para el kernel?
    • (REG) Hay muchos lugares los cuales proveen varios parches extra al kernel para nuevas características. Uno especialmente bueno es : http://www.linuxhq.com/.
  9. Qué es un parche?
    • (RRR) Un archivo parche (refiriendose al Linux kernel) es un archivo de texto ASCII el cual contiene las diferencias entre el código original y el nuevo código, además de información adicional tales como nombres de archivo y número de lineas. El programa patch (man patch) puede entonces aplicar un parche a las fuentes existentes de un árbol de kernel .
  10. Cómo hago que un parche sea adecuado para la lista de correo del linux kernel?
    • (REG) Aquí hay algunas lineas de guía para postear parches. Para información acerca de como generar parches, mira la entrada por RRR abajo.
      • Asegurate de que el parche no tenga caracterres de terminación control-M en cada línea. Un número de herramientas rotas usadas para codificar parches añanden control-M para "compatibilitidad con el DOS". Esto rompe muchas versiones de patch, por eso asegurate de configurar bien tus herramientas adecuadamente, o usa herramientas irrompibles, de otra forma tu parche será eliminado silenciosamente.
      • Incluye tu parche inline en el correo, en texto plano. No lo postees como un adjunto MIME base64. Mucha gente NO será capaz de leer tu parche, y por eso tu parche se eliminará sin comentario.
      • Si tienes un parche grande, postea mejor una URL, de otra forma llenaras los buzones (buzón) de muchas personas, y tendras quejas (bounces). Postear un nuevo parche grande, una vez que puede estar OK, pero las actualizaciones no deben ser posteadas completas (postea una URL).
      • Si quieres que Linus o alguno de los encargados principales (i.e. Marcelo, David) aplique tu parche, debes Cc: a ellos explicitamente, de otra forma tu parche sera ignorado.
      • Cuándo envies parches a Linus o a alguno de los encargados primarios, debes incluir el parche inline, en texto plano, no importa el tamaño del parche.
      • Si quieres enviar el parche a la lista para comentarios, También envialo a Linus /encargados primarios para inclusión, y si el parche es grande, querrias sabes com reconciliar los conflictos de requerimientos. La solución es obia: postea la URL a la lista de correo, espera por comentarios, y despues envia el parche, inline, a Linus/encargados primarios. Si, esto es más trabajo para ti. No, nos preocupamos por eso.
      • Si tienes un mailer que come espacio en blanco o causa similar corrupción, entonces CORRIGE TU MAILER, no esperes ser capaz de tomar la solución fácil y codificar el parche como MIME .
      Finalmente, He mirado la pregunta de alguien acerca de estas lineas de guía, stating que las reglas rather más relaxed, y estas FAQ estan siendo over zealous. Afortunadamente, el Rey Pinguino por si mismo ha respondido a esto, Por eso incluyo sus palabras en esto, entonces que no quepa duda: 
      Si recibo el parche como adjunto (otro del tipo adjunto "text/plain" 
sin importar que tan bueno sea todos los lectores de mail y todas las herramientas lo veran
como cuerpo normal), Simplemente NO lo aplicare a menos de que tenga una razón de
peso para hacerlo. Usualmente el joderme mirandolo,
A menos que espere algo especial de quien envia.

De verdad. No envies parches como adjuntos. 

		Linus
    • (RRR) Para hacer un parche usas el programa diff (lee el archivo info para diff). La forma más fácil de hacer esto es establecer dos arboles fuentes dentro de /usr/src, hacer un vinculo simbólico "/usr/src/linux" que apunte al árbol modificado, y haces diff uno contra el otro. El archivo /usr/src/Documentation/CodingStyle tiene información más específica, leelo!. Cosas para recordar:
      • Siempre específica el formato diff unificado (-u).
      • Rechaza hace formateo de los cambios de las fuentes que hagan el diff necesariamente menos grande. Mira editores que conviertan los espacios tabuladores o viceversa.
      • A menos que tengas razones especifícas, haz diff contra el ultimo árbol oficial. De otra forma, tu parche sera ignorado. De cualquier forma, específica en tu posteo en contra de lo que haz hecho diff.
      • Asegurate de que tu diff incluya solo los cambios necesarios en tu parche, no otros parches que hayas hecho a tu árbol fuente. Usualmente los parches estan limitados a pocas lineas, o directorios. Es mejor solo hacer diff solo a los archivos relevantes ej Si solo he hecho cambios al driver_xyz.c bajo drivers/net, Entonces usaria los siguientes comandos (asumiendo que tu árbol fuente original se llama "linux-2.1.105", y el árbol modificado apunta al vinculo simbólico "linux"): 
        cd /usr/src
diff -u linux-2.1.105/drivers/net/driver_xyz.c            \
                linux/drivers/net/driver_xyz.c  > my_patch
      • Las siguientes dos deberian ir sin decir: los argumentos para diff son primero la fuente (la original, archivo(s) sin modificar), y entonces destino (tu versión modificada de los archivo(s)), de otra forma conseguiras un parche reverso (y mucha gente creera que estas fumando).También, asegurate de que tu parche compile limpiamente.
      • Por supuesto que necesitas establecer dos directorios fuentes identicos para ser capaz de hacer diff despues. Un buen truco -- requiere un poco de consideración, piensa -- es crear el árbol fuente modificado desde vinculos duros a lal árbol fuente original: 
        tar xzvf linux-2.1.algo.tar.gz
mv linux linux-2.1.algo.orig
cp -al linux-2.1.algo.orig linux-2.1.algo

        Esto hará vinculos duros para todos los archivos fuentes del árbol original a una nueva ubicación; esto es muy rápido, por que no necesita crear 80+ megabytes de archivos. Ahora puedes aplicar parches al árbol fuente linux-2.1.algo, desde que el parche no modifique los archivos originales pero los mueva a nombredearchivo.orig, por eso los contenidos del archivo con vinculo duro no cambiaran.

        Asumiendo que tu editor hace lo mismo, También (mueve los archivos originales para hacer copia antes de escribir los que han cambiado) puedes También libremente editar con el árbol fuente con vinculo duro. Si tu editor no maneja archivos de esta forma, necesitas hacer copia de cada archivo antes de editarlo, como esto: 

        cp driver_xyz.c temporary; mv temporary driver_xyz.c

        Puedes usar permisos de archivos para recordarte hacer esto. Solo quita los permisos de escritura de todos los archivos del directorio en el cual trabajas: 

        chmod -w *.c

        El árbol modificado puede ser diffed a alta velocidad, desde que la mayor&iaacute;a de archivos no tengan contenido identico, Son archivos identicos en ambos arboles. Naturalmente que removiendo ese árbol es rapido, También. Gracias a Janos Farkas <chexum@shadow.banki.hu> por este truco.

      • Finalmente, revisando el archivo parche (el formato de archivo no es complicado) antes de postearlo, y incluir toda la información relevante como la naturaleza del parche. En particular, específica: Por qu&e el parche es &uacte;til/necesario, y exactamente que es lo que corrige/implementa.
  11. Cómo aplico un parche?
    • (TAC) (de /usr/src/linux/README) Puedes actuzalizar entre lanzamientos parchando. Los parches se distribuyen en el tradicional gzip y el nuevo formato bzip2. Para instalar parchando, consigue todos los archivos parche más nuevos, entra al directorio de un nivel-arriba del árbol de las fuentes del kernel y ejecuta:
      gzip -cd patchXX.gz | patch -p1 or:
      bzip2 -dc patchXX.bz2 | patch -p1
      (repite xx para todas las versiones mayores que la versión actual de tu árbol fuente , en orden) y deberia estar bien. Puede que quieras eliminar los archivos de copia de seguridad (xxx~ o xxx.orig), y asegurar que de que no hay parches fallidos (xxx# or xxx.rej). Si los hay, en cualquiera de ellos tu o yo hemos cometido un error.
      Alternativamente, el script patch-kernel puede usarse para automatizar este proceso. Este determina la versión actual del kernel y aplica cualquier parche que se encontre. Usalo de este modo:
      scripts/patch-kernel .
      El primer argumento en el comando es la ubicación de las fuentes del kernel. Los parches son aplicados desde el directorio actual, pero puede especificarse un directorio alterno como segundo argumento.
    • (RRR) Para aplicar parches por favor echa un vistazo al archivo README (/usr/src/linux/README) bajo la Sección "Instalando el kernel". También hay una buena explicación en el sitio del proyecto HQ (Head Quarters - Cuarteles) de Linux.
  12. Todos hablan de un "árbol CVS en vger". Qué es vger? Y Qué es un árbol CVS?
    • (REG) Aparte de la referencia de Star Trek, vger.kernel.org es una lista de correo y un servidor Web que sirve fielmente a la comunidad Linux. Un árbol CVS de desarollo de kernel esta también disponible en http://vger.samba.org/ y es un árbol CVS, el cual es un mirror actualizado del árbol maestro de vger.kernel.org. Notese que este árbol CVS no es el árbol oficial de kernel, es meramente el campo de juego de algunos hackers del kernel de alto-perfil. El árbol oficial es mantenido por Linus Torvalds y esta disponible en http://www.kernel.org/ el cual tiene mirrors mundiales. David Miller (el encargado del árbol CVS de vger) envia periodicamente los parches de Linus del árbol CVS. Entre otras cosas, el árbol CVS de vger es donde se desarollan y prueban los parches Sparc, Sparc64 y parches para modelo de trabajo en red (networking).
  13. Dónde puedo encontrar más información acerca de CVS?
    • (ADB) La mayor&iaacute;a de distribuciones GNU/Linux incluyen CVS. También puedes echarle un vistazo a La página CVS de Bubbles.
  14. Hay algún tutorial CVS en algún lado?
    • (ADB) Aquí hay un tutorial CVS el cual puedes encontrar en línea: Conseguir una idea acerca de como trabaja CVS toma 15 minutos (altamente recomendado). Notese que hay varios frontends graficos para CVS, entonces no tienes que aprender la clasificaci&aocte;n de los comandos ocultos.
  15. Cómo introduzco mi parche dentro del kernel?
    • (RRR) Dependiendo de tu parche hay muchas formas de introducirlo al kernel. Lo primero que hay que hacer es determinar bajo que encargado esta tu código (mira el archivo MAINTANERS). Si tu parche es solamente una pequeña correcci&aocte;n de un bug y estas seguro de que esta 'obiamente correcto', entonces de todas formas enviaselo al encargado adecuado y postealo a la lista. Si hay urgencia por la correcci&aocte;n del bug (ej. un hoyo de seguridad mayor) puedes enviarlo a Linus directamente, pero recuerda que el ignora parches aleatorios a menos que sean "obiamente correctos" para el, si tiene la aprobaci&aocte;n del encargado, o han sido bien probados y encuentran la primera condición. en caso de que quieras de que se considere como bien-probado, aquí hay otro importante consejo: uno de los propositos de la lista es conseguir parches por-revisar y bien-probados . Ahora, si tu parche es relativamente grande, ej. la reescritura de la sección, un gran código o un nuevo driver para dispositivo, entonces conserva el ancho de banda y el espacio en-disco y postea un anuncio a la lista con un vinculo al parche. Ultimamente, Si no estas muy seguro de tu parche para kernel aún, y quieres algo de retroalimentacion por parte del encargado, o deseas evitar la ardiente temporada-abierta de trabajo-en-progreso, entonces usa el mail privado.
    • (REG) Si no hay encargado específico para la parte del kernel que quieres parchar, entonces tienes tres opciones principales:
      • envialo a linux-kernel@vger.kernel.org y espera que alguien lo recoga y lo envie a Linus, o talvez Linus por si mismo lo haga (no cuentes con eso!)
      • envialo a la lista del linux kernel y pon Cc: Linus Torvalds <torvalds@transmeta.com> y espera que Linus lo aplique. Notese que Linus opera como una caja negra (black box). No esperes una respuesta de el. Necesitaras chequear los parches que el lanza y mirar si ha aplicado tu parche. Si no aplica tu parche, necesitaras re-enviarserlo (usualmente muchas veces). Si despues de semanas o meses y muchos lanzamientos de parches el aún no lo ha aplicado aún, talvez deberias rendirte. A el problablemente no le gusto.
      • envialo al las lista del linux kernel y pon Cc: Alan Cox <alan@redhat.com>. Alan es mejor respondiendo mails, y enlistara tu parche y lo re-envia a Linus periodicamente, entonces puedes olvidarlo. El También sirve como un tester de buen tacto. Si Alan acepta tu parche, es más probable que Linus también. Si no le gusta tu parche, probablemente recibas un mail diciendolo También. Espera que sea breve.
  16. Por qué el tarball del kernel contiene un directorio llamado linux/ en vez de linux-x.y.z/ ?
    • (DW) Por que esa es la forma que Linus quiere. Hace que aplicar parches muy consecutivos sea más simple, por que no se necesita renombrar el directorio cada vez, y esto hace la vida más fácil para Linus.
  17. Cuál es la diferencia entre los kernels oficiales y la series de parches Alan Cox's -ac?
    • (REG, contribuido por Erik Mouw) Los kernel de Alan pueden parecer una prueba de cama para los kernel de Linus. Mientras Linus es muy conservativo y solo aplica parches obios y bien probados al kernel 2.4, Alan mantiene una serie de parches para el kernel que contienen nuevos conceptos, más y/o nuevos drivers, y parches más intrusivos. Si los parches demuestran ser estables, Alan los presenta a Linus para incluirlos en el kernel oficial.
  18. Qué significa para un modulo ser 'tainted' ?
    • (REG, contribuido por John Levon) Algunos vendedores distribuyen modulos binarios (modulos sin código disponible bajo una licencia libre de software). como el código no esta libremente disponible, algún bug no puede ser cubierto para ser investigado por los hackers del kernel. Todos los problemas descubiertos mientras tal modulo esta cargado, debera reportarse al vendedor de ese modulo, no a los hackers del Linux kernel, ni a la lista de correo del linux kernel. El esquema de 'tainting' se usa para identificar reportes de bugs de kernels con modulos binarios cargados: tales kernels estan marcados como "tainted" por terminos del tag MODULE_LICENSE. Si el modulo cargado no específica alguna licencia aprovada, el kernel se marca como tainted. La lista canonica de cadenas de licencias aprobadas se en encuentran en: linux/include/linux/module.h.
      reportes de "oops" marcados como 'tainted' no son de uso de los desarrolladores de kernel y seran ignorados. Una mensaje de Warning (advertencia) aparece cuando se carga el modulo. Notese que puedes verni de las fuentes del modulo que esta bajo una licencia compatible, pero no tiene la etiqueta adecuada MODULE_LICENSE. Si ves un warning (advertencia) de modprobe o insmod para un modulo bajo una licencia compatible, por favor reporta este bug a los encargados del modulo, así ellos podran añadir la etiqueta necesaria.
    • (KO) Si un símbolo se ha exportado con EXPORT_SYMBOL_GPL entonces este aparece como no resuelto para modulos que no tienen una cadena MODULE_LICENSE compatible GPL, e imprime un warning (advertencia). Un modulo puede también 'taint' el kernel si haces una carga forzada. Esto pasa el chequeo de verificaci&aocte;n del kernel/modulo y el resultado es indefinido, cuando esto se rompa tendras que mantener los fragmentos.
    • (KO) Deacuerdo con Alan Cox, una licencia de "BSD sin clausula de advertencia" no es una licencia libre adecuada de software. Este tipo de licencia permite modulos binarios unicamente sin código fuente. Algunos modulos en el tarball del kernel con esta licencia deberian ser realmente ser "Dual BSD/GPL".
  19. Qué hay acerca de los símbolos GPLONLY ?
    • (REG) Por defecto, los símbolos se exportan usando EXPORT_SYMBOL, por eso ellos pueden ser usados por modulos cargables. Durante la serie 2.4, se añadio una nueva directiva de exportado EXPORT_SYMBOL_GPL. Esto casi es lo mismo, excepto por que el símbolo solo puede por modulos que tienen licencia compatible GPL (notese que esto incluye el código de doble licencia BSD/GPL). Esta nueva directiva se añadio por estas razones:
      • Para clarificar los campos ambiguos que mienten en algunos modulos no-GPL (particulamete proprietarios). Una lectura estricta de la licencia GPL prohibe la carga de modulos propietarios en el kernel. Mientras Linus ha sostenido consistentemente que los modulos propietarios son perimitidos (i.e. el ha garantizado la exclusion exclusiva), esta claro que no es muy claro para hablar con todos los desarrolladores que han contribuido al Linux kernel. Mientras muchos de los pensamientos de edicto de Linus dice que todo el código que ha contribuido cae bajo esta exclusion garantizada por Linus, no todos estan deacuerdo que esto suene legalmente como un argumento. La nueva directiva EXPORT_SYMBOL_GPL hace explicitos los terminos de licencia, y entonces remueve la ambigueidad legal.
      • Para perimitir a los desarrolladores quienes deseen, por sus propias razones, para contribuir código que no pueda ser usado por modulos propietarios. Tal y como el desarrollador tiene el derecho de distribuir código bajo una licencia propietaria. Por eso también un desarrollador puede distribuir código bajo una licencia anti-proprietaria (ej. GPL estricta).
      Notese que Linus sostiene que los modulos existentes no podran ser cambiados a solo GPL. Desarrolladores de modulos propietarios para Linux no deben asustarse. Además, es de considerar que a menos que Linus cierre nuestra favorable oportunidad para la introducción de nuevas API de los principales drivers las cuales pueden estar restringidas a modulos solo-GPL. Esto podria no estar en los mejores intereses de Linux. Linus me ha reenviado un mensaje el se lo envio al alguien más para aclarar sus puntos de vista.
  20. Tengo que usar BitKeeper para enviar parches?
    • (REG) Absolutamente no. Algunos desarrolladores, incluyendo a Linus y Marcelo, han escogido BitKeeper para manejar sus arboles de fuentes de kernel, pero esto no significa que tengas que usar BitKeeper para para mantener tus arboles o enviar parches. Muchos desarrolladores destacados de kernel continuan manteniendo sus arboles de fuentes usado otras técnicas y herramientas, y continuan enviando parches convencionales.
      Si quieres usar BitKeeper para manejar y enviar tu código, el directorio Documentation/BK-usage tiene alguna información y scripts ejemplos que contienen utiles sugerencias. Esta documentación y código no es una confirmaci&aocte;n de BitKeeper.
  21. Por qué algunos desarrolladores usan el BitKeeper no-libre ? No va esto en contra del espiritu de Software Libre?
    • (REG) Esto depende de la definicion de "libertad" que estes usando, y de lo que pienses acerca del significado de "Software Libre". Algunas definiciones estan disponibles en http://www.gnu.org/philosophy/free-sw.html, http://www.debian.org/social_contract.html y http://www.opensource.org/docs/definition_plain.html.
      Si te suscribes para ver todo el software que quiere ser libre (y de aquí que todo el software no-libre/proprietario es malo), entonces si, el uso BitKeeper va en contra del espiritu del Software Libre.
      Sin embargo, si tienes más cuidado acerca de libertad para los desarrolladores de software para desarrollar el mismo y usar cualquier herramienta que ellos deseen, entonces el uso de BitKeeper va con el espiritu del Software Libre, desde que algunos desarrolladores sienten que BitKeeper les ahorra mucho tiempo y esfuerzo. Esto es bueno para el desarrolladores del Software Libre.
      Este es un debate ideologico en el que algunas personas no estaran deacuerdo y genera considerable polemica en ambos lados del argumento. Hablando acerca de ello en la lista de correo del desarrollo del linux kernel, no resolvera este dilema, no hay problema en cuan duro o cuantas veces grites, por eso esto es mejor que aquellos que se sienten más fuertes acerca del debate los puntos más finos de libertad en algún lado, y dejan las lista de desarrollo para problemas actuales de desarrollo de código, para lo cual se propuso la lista.
      Nota que BitKeeper no es software libre, pero puede usarse para Proyectos de software libre sin cargo, sujeto a reglas de licenciamiento (bk help bkl mostrara la licencia, o puedes ir a http://www.bitkeeper.com/manpages/bk-bkl-1.html).
      Si estas seriamente acerca del uso del manejo de una herramienta para un proyecto de Software Libre, el acercamiento más productivo para cambiar la situacion es escribir un reemplazo libre. Esto puede tomar a veces muchos años de trabajo, particularmente Linus es muy exigente. Es importante recordar que esto tomo años desde que BitKeeper fue "lo suficientemente bueno" para que satisfaga con su conjunto de características a Linux. Un reemplazo libre tendra la misma organizaci&aocte;n técnica. Larry McVoy (fundador de BitKeeper) comenzo en Abril 2002 cuando el esfuerzo de desarrollo fue: Esto tomo 4 años de por lo menos esfuerzos de 6 dias a la semana en un equipo de ingenieros que varió en tamaño de 3 a 8 ingenieros para llevar a BitKeeper donde esta hoy.
  22. Quién mantiene el kernel?
  23. El kernel no compila correctamente. Qué hare?
    • (REG) Primero asegurate de que tienes la ultima versión de la serie de kernel. Quizas un pre-parche ya tenga una correcci&aocte;n. Si no, busca en la lista de archivos para una correcci&aocte;n. No contribuyas al ruido en la lista preguntando algo que puede ya haber sido respondida.
      Si aún no soluciona el problema, trata explorando el código por ti mismo y postea una correcci&aocte;n a la lista de correo. Seras famoso! Ten cuidado que considerar hacer que el código roto compile solo para un limpio 'make bzImage modules' no cuenta como correcci&aocte;n, y tu correcci&aocte;n será descartada, ignorada o quemada.

Sección 2 - Preguntas Especificas acerca de drivers

  1. El driver tal y tal estan rotos (broken)!
    • (RRR) Trata de ser más específico. Por favor, provee información de tu configuración particular (mira Preguntas Cómo hago un reporte de bug? ) También mira P: "kernel x.y.z roto (broken)!" .
    • (ADB) Esta es la peor forma de comenzar un hilo. Por favor trata de contactar primero al autor del driver y reportarle el driver "roto". Las Criticas constructivas son bienvenidas, usualmente.
  2. Aquí hay un nuevo driver para un hardware XYZ.
    • (REW) Buen trabajo! Por favor trata de encontrar algunas personas que tengan ese hardware xyz y has, que lo prueben en su configuración (e.j. posteando una noticia en un grupo de noticias). No ira en el kernel estandar que algunas personas hayan probado.
      Las pruebas tomaran un tiempo. A la hora de la verdad, el desarrollo del kernel continuara, y tendras que reescribir tu parche para la mayor&iaacute;a de versiones recientes antes de que Linus pueda considerarlo.
      Cómo todo nuevo driver es mayor que unas pocas páginas de largo, nosotros prefeririamos si pones arriba el driver por FTP en vez de postearlo a la lista. Postea el URL y la descripci&aocte;n que nos dice lo que hace tu driver para que hardware.
  3. Hay algún soporte para mi tarjeta TW-345 modelo C en la versión de kernel f.g.hh?
    • (REW) Primero verifica si tu tarjeta es autodetectada en el arranque. Usualmente lo hace. Segundo mira si puedes necesitar configurar algo para tu tarjeta, en modules.conf. Tercero mira si hay un archivo con el nombre de tu tarjeta en las fuentes del kernel. (e.j. tienes una tarjeta Buslogic, y hay un archivo buslogic.c en las fuentes del kernel, estas de suerte!.). A continuación, busca por el nombre del fabricante a través de TODO el árbol de las fuentes del kernel. y trata de encontrar el número de modelo de tu tarjeta . También trata de encontar el chip más grande en la tarjeta y localizar el número del chip. Dese cuenta que el chip 53C80 puede llamarse 5380 en el kernel. A otros chips no se les ha quitado su nombre de en medio.
      Nada aún? Ahora echale un ojo a DejaNews, usando los mismos argumentos que usaste para buscar en el árbol de las fuentes del kernel. Hay un 99.99% de que alguien tenga exactamente la misma tarjeta TW-345 modelo C.
      Ok. Eso es lo que puedes hacer sin molestar a nadie. Si todo esto no te lleva a algún lado, deberias verdaderamente hacer esta pregunta en un grupo de noticias como comp.os.linux.hardware.
  4. Quién Mantiene el driver tal y tal?
    • (RRR) Echa un vistazo al archivo /usr/src/linux/MAINTAINERS, esta es la fuente más autoritaria. También verifica en el código del driver por si mismo; en ambos casos, verifica que tengas la ultima versión disponibles del kernel. Algunos drivers tienen Sitio Web específico y a veces han dedicado una lista de correo. Verifica eso primero. Si no puedes contactar al responsable entoces como ultimo recurso postea un corto mensaje a la lista. En cualquier caso, ten en mente que los responsables, son personas muy muy ocupadas y la mayor&iaacute;a de ellos trabajan en Linux gratis y dedican su tiempo de esparcimiento, por eso no esperes una respuesta inmediata. Algunos responsable reciben demasiados mails en cortos periodos de tiempo para ser capaces de responder todos ellos, por eso por favor se amable con ellos.
  5. Quiero escribir un driver para la tarjeta TW-345 modelo C, como comienzo?
    • (REW) Buena inciativa! Primera parte del aviso: estas en condiciones de hacerlo? Diez veces como en muchos proyectos como comienzan, terminan. También, asegurate de que no estas haciendo doble trabajo. Asegurate que tal driver no esta disponible ya: lee P/R 2.3 abajo...
      Primero preparate a ti mismo. Consigue la documentación, leela (OK, tienes permiso de comenzar saltando si ya has encontrado la parte "descripciónes detallados del registro"). A continuaci&aocte;n, consigue las fuentes del Linux kernel, encuentra un driver que maneje un hardware similar al cual tu estas trabajando, y lee ESO. (Usualmente, uso el más pequeño que puedo encontrar :
       wc -l *.c | sort -n | head -4)
      .
      Ok. Ya haz pensado sobre eso. Ahora la pregunta es, tienes la documentación técnica para tu tarjeta? puedes hacer ingenieria inversa para los sistemas operativos MS, pero si tienes la documentación será MUCHO más fácil.
      En las antiguas y oscuras épocas (70's hasta mediados de los 80's), conseguias la descripción técnica con todas las tarjetas que podias conseguir. Esto no se dio más. De todas formas, contacta al vendedor de la tarjeta y preguntale educadamente por ella (documentación) "kit de driveres del dispostivo" o por el "manual técnico" para la tarjeta.
      Trata en la oficina principal y a la oficina local al mismo tiempo. Las oficinas locales ocasionalmente tienen malas fotocopias, que ellos les dan antes que te hagan un rechazo, de la oficina principal. En ese caso por quien podras conseguir la documentación que se convierte en información confidencial. No pongas los nombres de esos chicos en el código.
      Si no puedes conseguir la documentación técnica, considera rendirte e investigar acerca el producto en competencia (y dile al fabricante acerca de esto). No consigues nada a&uactute;n? Ok. El siguiente paso es encontrar que hace el driver de DOS. trata de hacer funcionar mientras corre en un emulador de DOS (dosemu o WINE). Esto te permite programar basandote en los registros de los accesos de E/S del driver. Esto te dara una gran lista de los accesos de E/S que hizo el driver. Si eres bueno, puedes ser capaz de ver patrones, y deducir como trabaja el driver. De alla puedes se capaz de escribir un driver que funcione. Buena Suerte! La necesitaras.
  6. Quiero conseguir la doc, pero ellos quieren que firme un NDA Non-Disclosure Agreement (Acuerdo de No-Descubrimiento).
    • (REW) Algunas personan encuentran en esto un tremendo problema. Algunas compañias solo quieren saber quien tiene la documentación para su hardware, y no se preocupan si alguien escribe un driver GPL. En ese caso de verdad que no hay problema: solo diles que es lo que intentas hacer y preguntales acerca del conocimiento escrito que ellos han entendido lo que tu dices. En ese caso, podras incluir tu driver en el kernel estandar pero no puedes mandar los docs a quien quiera trabajar en el driver. Ellos tendran que confiar en los comentarios el las fuentes.
      Otras compañias (solo como Netscape) han firmado por ellos mismos acuerdos NDAs que les prohibe mostrarte el código.
      Algunos realmente piensan que ellos tienen secretos comerciales en la interfaz a través del software, e intentan mantenerlos en secreto. Estos no te permitiran escribir un driver y poner las fuenetes en la red. Se cuidadoso con esto.
    • (ADB) El primer y único NDA que he recibido instantaneamente encontro su camino hacia la basura. Advertiría a alguien que reciba un NDA resistirse a firmarlo, si este se refiere a algo que puede/o sera puesto bajo GNU/GPL. Por supuesto, esto no se aplica para contrato de trabajo.
  7. Quiero/necesito/debo tener un driver para una tarjeta TW-345 modelo C! Nadie escribira uno para mi?
    • (REW) Algunos desarrolladores de Linux desarrollaran el driver para ti por una cerveza. Otros querran querran una "muestra gratis" del hardware y entonces procederan a escribir el driver.
      Si necesitas más que un par de tarjeta o tú mismo vendes las tarjetas, puedes considerar el pago de uno de los drivers comerciales para dispositivos para conseguir un driver comercialmente pagado, y oficialmente mantenido.
  8. Qué es el número mayor/menor de un dispositivo?
    • (REG) Los números de dispositivos son el camino tradicional de Unix para proveer un mapeo entre el sistema de archivo y los drivers de dispostivos. Un número de dispositivo es una combinaci&aocte;n de un número mayor y un número menor. Actualmente Linux tiene 8 bit de mayores y menores. Cuándo abres un archivo dispositivo (dispositivo caracter o por bloques) el kernel toma el mayor número del inodo y lo indexa en una tabla de punteros de la estructura del driver. La estructura específica del driver se usa para llamar al metodo open(), el cual en turno podra interpretar el número menor. Hay dos tablas: una para los dispostivos caracter y una para los dispositivos por bloques, cada una tiene máximo 256 entradas . Obiamente, deben estar deacuerdo entre los números de dispositivos usadosen el driver y los archivos en /dev. Las fuentes del kernel tienen el archivo Documentation/devices.txt el cual es una lista oficial de los números mayores y menores. H. Peter Anvin (HPA) mantiene esta lista. Si escribes un nuevo driver (para consumo público), necesitaras conseguir un número mayor ubicado por HPA. Mira la P/R en devfs para un mecanismo mejorado para manejo de drivers para dispositivos (IMHO) .
  9. Por qué los WinModems no estan soportados?
    • (REG, citando a Edward S. Marshall) El problema es la falta de especificaciones para este hardware. La mayor&iaacute;a de empresas que proveen los llamados "WinModems" se resisten a proover especificaciones las cuales permitirian usarlos en los sistemas operativos "No-Microsoft".
      La idea básica es que ellos no trabajan como un modem tradicional; estos no tienen DSP (Procesador Digital de Señales), en vez de esto, hacen que la CPU haga todo el trabajo. de aquí que no les puedas hablar como a un modem tradicional, y necesitas ejecutar el driver del modem como una tarea en tiempo real, o tendras serias perdidas de datos bajo cualquier tipo de carga. Ellos son simplemente un diseño pobre.
    • (REG) Notese que algunas personas han puesto el esfuerzo en la ingenieria inversa a algunos WinModems, por eso puedes estar de suerte, y encontrar que el tuyo ahora ya esta soportado. Si no, es tiempo de ahorrar y comprar un buen modem.
      Notese que los modems tienen que sear aprobados por los estatutos o el cuerpo regular para estandares de consentimiento (para asegurarse que no envian abajo la línea y colapsan el intercambio). Con los WinModems, el software del driver necesita también estar certificado tal como lo hace el hardware. Es más duro de conseguir la aprobaci&aocte;n de drivers Open Source, desde que cuesta dinero obtener la aprobaci&aocte;n. También, en teoria, es más fácil modificar un driver Open Source, por eso no estara más calificado. En realidad, 99.999% de los usuarios no saben que hay un código fuente para el driver que debe estar deacuerdo con los Estandares de Consentimiento, puede verse como un dudoso para fabricantes que no se quieren molestar con sistemas no-WinTel. Si la certificaci&aocte;n fue el unico problema, los fabricantes pueden lanzar drivers unicamente-binarios.
    • (DW)La buena noticia es que una cierta cantidad de hardware WinModem esta ahora soportado. La mala noticia esta cantidad es como la punta de un iceberg. Sin embargo los WinModems ahora pueden usarse, por que tienen funcionalidad similar a la de una tarjeta de sonido - toda la modulaci&aocte;n y de demodulaci&aocte;n tiene que ser realizado por la CPU. El trabajo en este frente esta progresando también - Mira http://www.linmodems.org/ para información más actualizada.
  10. Las CPUs modernas son muy rapidas, entonces por qué no puedo escribir un manejador de interrupciones para modo usuario?
    • (REG, citando a Pete Zaitcev) Esta no es una pregunta acerca de tener suficientes ciclos de CPU para desperdiciarlos en cambios de modo. Mejor dicho, la arquiectura actual de Linux no lo permite. Los procesos de usuario se ejecutan con las interrupciones habilitadas. Por eso, cualquier manejador de interrupciones debe desactivar la fuente particular de interrupción antes de que un proceso sea planificado para ejecutarse, o la interrupción resulta tormentosa. La desactivacion se hace de manera específica en el dispositivo, entonces por lo menos un pequeño driver de dispositivo debe estar en modo kernel.
  11. Necesito probar mi driver en todas las distribuciones?
    • (REG, MEA) Hay un menor número de detalles de cambios entre cada versión de kernel (el las series estables), y dependiendo de que configuraciones se usen (básicamente SMP o no), cosas certeras como los spinlocks pueden o no reservar espacio en las estructuras, y puede o no necesitar ser llamados (estan bien optimizadas en sistemas no-SMP), significa que un driver binario compilado para SMP puede que no trabaje con un kernel no-SMP. Y vice versa.
      También diferentes vendedores tienden a incluir cosas distintas en sus juegos de parches para kernel, los cuales pueden incluir cambios en el diseño de datos, etc. En las series estables de kernel se han sufrido grandes dolores en el mantenimiento, por que los diseño de datos en las APIs del kernel (Y las API se llaman a si mismas) no se han cambiado. No obstante algo puede cambiar haciendo drivers binarios, fallar de forma misteriosa.
      Sutiles cambios de memoria pueden aparecer con el modo i386-PAE (máquinas con bastante memoria las cuales no pueden mapear toda la RAM en el kernel al mismo tiempo).
      A causa de esas diferencias, un driver compilado para una versión de kernel, o una de vendedor de kernel, no es como trabajar con otro kernel. Por eso, si distribuyes drivers solamente-binarios, tendras soporte significativo para la compilación y carga en kernels diferentes. Si distribuyes un driver desde las fuentes, entonces, el driver provisto esta bien-escrito (e.j. no asume acerce del orden de bytes, o tamaño de las palabras, y usa las intefaces estandar del kernel), el driver debe ser portable a través de varias versiones de kernel versiones y tipos de arquitectura. Por supuesto tendra que ser compilado por usuarios finales para su kernel particular. Los responsables de la mantención de una distribuci&aocute;n son los que más estan deacuerdo en proveer drivers pre-compialdos, por eso la mayoría de usuarios finales no necesitaran compilar el driver por ellos mismos.

Sección 3 - Preguntas acerca de la lista de correo

La lista de correo del linux kernel es para la discusión del desarrollo del Linux kernel por este mismo. Preguntas acercas de adminstración acerca de un sistema basado en Linux, programaci&aocte;n en un sistema Linux o preguntas acerca de una distribuci&aocte;n Linux no son apropiadas.

Mensajes del tipo "Test" son muy, muy inapropiados en la lkml o en cualquier otra lista, para ese problema. si quieres saber que si te suscribes, deberas esperar un par de horas antes que que te llegue un reply a la lista de correo de software diciendo que ya lo hizo. Evidentemente te llegaran un número de mensajes provenientes de la lista. Si quieres saber si los puedes postear, tienes que decir algo importante, de acuerdo? Despues de que hayas leido los siguientes párrafos, redacta una carta verdadera, no un mensaje de prueba, en un editor, guardando el cuerpo de la carta en caso de que no se pueda postear el mensaje. Entonces ya puedes postearlo a la lkml. Por favor recuerda que hay bastantes personas suscritas a esta lista, y tomara un rato para que tu carta sea respondida. Una hora no es demasiada espera.

(REG) El punto escencial para recordar cuando se postee a la lista de correo del linux kernel es que hay mucha gente ocupada leyendo la lista. No hay problema cuan importante pienses que es, it is most likely que hay mucha gente en la lista quien es más importante que tu. el carácter de "Importante" no se mide por la cantidad de dinero que tengas, Que tan importante es la pregunta para tu compañia o cuan desesperado estes por una respuesta, Mejor, se mide por cuento hayas contribuido al linux kernel.

Con eso en mente, deberias asegurarte que no desperdicias el tiempo de otras personas en la lista. Escribe para un máximo de eficiencia de lectura. No importa si te toma dos veces escribir un mensaje más legible, esto les reduce a la mitad el tiempo a los desarrolladores clave del kernel el tratar de decodificar tu mensaje. El Ignorar el buen sentido y consideración resultaran que la mayoría te ignore.

  1. Cómo me suscribo a la lista de correo del linux kernel?
    • (ADB) Piensalo de nuevo antes de suscribirte. En verdad quieres obtener todo ese Tráfico en tu buzón? Estas concientizado acerca del desarrollo del Linux kernel, que aplicaras parches a tu kernel una vez a la semana, sufriendo los oops, bugs y las resultantes perdidas de energia y tiempo? Estas listo para unirte a la Gran Orden del Gran Gran Pinguino, y seras llamado un "Geek de Linux" por el resto de tu vida? Talvez mejor podrias leer la entrega semanal del "Tráfico del Kernel en http://kt.zork.net/.
      OK, si aún quieres leer la lista del linux-kernel esta en completa gloria, enviar la línea "subscribe linux-kernel tu_email@tu_ISP" en el cuerpo del mensaje a majordomo@vger.kernel.org (no incluyas los caracteres " , y por supuesto reemplaza la dirección de ejemplo con tu dirección verdadera). Se te ha advertido!
    • (MEA) Por quée a menudo veo cosas como las muestra este sumario: 
      Fallón:
  <smtp cedar-republic.com edmond@cedar-republic.com 60000>: ...\
        <<- RCPT To:<edmond@cedar-republic.com>
        ->> 550 <edmond@cedar-republic.com>... we do not relay
      Enviando esta dirección a una página en la URL: http://vger.kernel.org/mxverify.html produce información acerca UNO de sus servidores de copia de seguridad MX el cual rechaza enviarles correos. De este modo siempre que todos los otros servidores fallen por ser inaccesibles, el otro arruina la conectividad del correo.

      Asegurate de que NO tienes este grave problema!
      Vea http://vger.kernel.org/majordomo-info.html para información en Majordomo.

  2. Cóomo me desuscribo de la lista de correo del linux-kernel ?
    • (ADB) Al final de todos los mensajes enviados por el servidor de la lista de correo del linux-kernel puedes leer:
      -
      Para desuscribirse de esta lista : envia la línea "unsubscribe linux-kernel" en
      en el cuerpo del mensaje a majordomo@vger.kernel.org
      Ver http://vger.kernel.org/majordomo-info.html para información en Majordomo.
  3. Tengo que estar suscrito para postear a la lista ?
    • (ADB) No, no tienes que estar suscrito para postear a la lista. La dirección de la lista es linux-kernel@vger.kernel.org. Y debes indicar en tu mensaje que deseas ser puesto en la copia del mensaje (CC:) para las respuestas / comentarios que es posteen a la lista como respuesta a tu comentario.
    • (REG) Eso es, sin embargo, considerado generalmente como una buena netiquette el estar suscrito a la listas (o a un grupo de noticias para ese asunto) y esconderse un rato antes de postear. De esa forma puedes aprender sobre lo que se considera un posteo adecuado y lo que no lo es.
      No trates la lista como tu ayudante personal. Recuerda que la lista es una communidad.
  4. Hay algún archivo de la lista?
  5. Cómo puedo buscar una pregunta específica en los archivos ?
    • (ADB) Usa palabras simples que se refieran a la issue que te interesa. Por ejemplo, si estas investigando sobre un oops que ocurren siempre que conectas a un adaptador de red NIC-007, usa "NIC-007" o "oops NIC-007". Tan pronto hayas encontrado en enlace al mensaje que te interesa, trata de seguir por el hilo (thread). Recuerda que casi siempre obtendras más información si haces una búsqueda más cuidadosa en el archivo, que posteando a la lista por sí misma.
  6. Hay otras formas de buscar información en la Web acerca de alg&aucute;n problema en particular del Linux kernel ?
    • (ADB) Seguro. Antes de que busques en los archivos de la lista, puedes buscar en DejaNews y AltaVista (simultaneamente, si tu navegador te permite tener abiertas varias ventanas). Puedes seguir algunos vinculos en el sitio Linux Documentation Project.
  7. Qué tan pesado es el tráfico en la lista?
    • (TAC) El tráfico de la lista es muy pesado; el promedio de mensajes por día es de 240 [10/2001 - 04/2002]. Eso es cerca de 7,200 mensajes al mes!!!
    • (ADB) En verdad no querras leer todos y cada uno de los posteos a la lista. Si eres conciente de este tráfico, Te sugiero que temporalmente intentes con las entregas de las listas en http://lists.us.dell.com/, lo cual sera más fácil en tu buzón (gracias a A. Wik por esta sugerencia).
    • (REG) Hay un sumario semanal llamado "Kernel Traffic" en http://kt.zork.net/, el cual te ahorrara mucho tiempo.
  8. Qué tipo de preguntas puedo realizar en la lista ?
    • (ADB) La regla básica es evitar las preguntas que se hayan realizado antes, las que son irrelevantes a otros usuarios de la lista, o las que estan fuera-de-tópico. Por favor usa tu buen sentido.
    • (REG) Recuerda que hay una lista de discusión del desarrollo del kernel . Si tienes alguna idea o reportes de bugs para contribuir, este es el lugar adecudado. Asuntos de espacio de Usuario no son apropiados para este foro. Si encuentras un bug en la librería C o alguna aplicación, no concierne al linux-kernel.
  9. Qué estilo de posteo debo usar para la lista?
    • (REG, contributed by thunder7@xs4all.nl) Cuando sigas un post en la lista del linux kernel, por favor piensa antes de citar. Desde que todos los demas en la lista también recibieron el post, no lo cites entero. Subraya solo los puntos que realmente son necesarios para entender tus argumentos. Asegurate de que la parte citada es reconocible tal como, asegurandose de que cada línea citada comienza con un > (o más >>, en el caso de una cita de multi-nivel). No cites firmas, parches, archivos de configuración enteros o posteos enteros. No cites la firma estandar. La lista del kernel esta suficientemente poblada ya, ten cuidado!
    • (REG) Ten en mente que es posible que tu mensaje sea borrado sin haber sido leido si tienes demasidado material citado antes de tu respuesta.
    • (REG) y por favor responde despues del texto citado, no antes (como en RFC 1855). es muy confuso mirar una respuesta antes del contexto citado. Y es vergonzoso: te hace ver como un novato. Cambia tu mailer si es necesario, si el que tienes te hace difícil responder del citando a.
      conozco a algunas personas que les gusta citar el mensaje entero al cual estan respondiendo, por eso ellos ponen su respuesta justo al inicio por eso la gente no se rendira despues de la primera página del material citado. No Lo Hagas. It's annoying. Solo aprende a parar de citando a todo. Nadie quiere verlos de todas formas (los archivos de la lista permiten a las personas ver todo si se lo han perdido). No te estas ayudando de ninguna forma, como vez es más posible que seas ignorado si contestas-antes-del-citando a
    • (REG) Por favor no uses tabuladores o espacios multiples para citar el texto. En vez usa la secuencia "> ". El uso de espacios en blanco para citar el texto hace difícil de diferenciar entre lo que esté citado y la respuesta. Y no trates de ser listo o "diferente" y usar algún otro caracter como "}" o lo que sea. De nuevo, es confundidor. desperdicia el tiempo de las personas. Escribe para máxima eficiencia de lectura.
    • (REG) Por favor trata de terner la gramática y escritura razonables. Cuando al leer el texto con verdadera mala gramática o escritura, la gente se detiene mientras trata de analizar tu posteo. No creas que estas siendo "artistico" saltandote todos los caracteres de los signos de puntuación. La lista del Linux-kernel no es una galería en línea, es un medio de comunicación. Escribe para máxima eficiencia de lectura.
    • (REG) Por favor trata de no poner firmas, candentes, controversiales u ofensivas (ve RFC 1855). La regla de la miniatura es de no más de 4 lineas de 80 caracteres cada una.
    • (PG) No adjuntes archivos enormes a tu posteo. Uno de los mayores errores de las personas es ajuntar el archivo .config de su kernel a sus posteos. Estos pueden exceder las 1000 lineas, y creceran más en cuanto se añ:aden más opciones al kernel. Si el contenido de tu archivo .config es relevante para tu posteo adjunta la salida de 
      grep ^C .config
      o 
      grep "=[y|m]" .config
      .
    • (MEA) Algunas estructuras estan prohibidas ya se usan demasiado en el correo SPAM. Especificamente, mensajes con el Content-Type: text/html también como el mensaje (primario), como ALGUNO de los sub-mensajes que lo componen se consideran como spam, y rechazados sin ninguna información al emisor.
      También, cualquier mensaje el cual su cabecera coincida con la expresión regular: X-Mailing-List:.*@vger.kernel.org se considera que esta en LOOPING en algún lado, y por lo tanto desviada al propietario de la lista.
  10. (REG) Si estas estancado usando using Microsoft Outlook u Outlook Express, los cuales han manchado citando ciertos algoritmos, deberias aplicar una de las siguientes correcciones: Estos corrigen estos mailers para ser más adecuados a los estandares.
  11. Es la lista moderada?
    • (ADB) No, la lista del linux-kernel no es moderada.
  12. Puedo ser expulsado de la lista?
    • (ADB) tecnicamente es posible, pero hasta ahora nunca he escuchado de alguien haya sido expulsado de la lista del linux-kernel.
    • (REW) Pero lo seras si posteas preguntas o respuestas que se preguntan o responden en estas PF (Preguntas Frecuentes). ;-)
    • (MEA) Oh definitivamente, todo lo que necesitas es un sistema de correo con mal funcionamiento el cual no acepta los correos para ti, -- verifica la copia de seguridad de tus dominios de servidores MX usando la herramienta que encuentas en: http://vger.kernel.org/mxverify.html
      se sabe que a través de los añs los encargados de las listas en en vger han eliminado a algunas personas despues de fastidiarse lo suficiente de ellos, pero para estar ahíi deberias excederte, y entonces obtener noble presión antes de ser expulsado.
      Otra forma de que te eliminen de la lista es usar el programa llamado "fetchmail" -- el cual por sí mismo no es malo, pero aparentemente de demasiado fácil accidentalmente re-postear correos a las dirrecciones los cuales tienen visieble las cabeceras RFC 822 -- eso es, lo que el autor original uso, como: To: linux-kernel@vger.kernel.org el resultado son mensajes duplicados en la lista de correo. Si permites que eso pase, puedes estar seguro de que tu suscripcion sera eliminada lo más pronto posible.
  13. Hay alguna regla(s) implicita en la lista a la cual tengo que tener cuidado?
    • (ADB) Aquí hay unas pocas reglas implicitas de las cuales debes tener cuidado:
      • Manten el asunto. Esta es una lista del linux Kernel, principalmente para desarrolladores.
      • Escribe Solamente en Ingles!
      • No postees en formato HTML!, Si usas IE o Netscape, por favor desactiva el formateo HTML para tus posteos a la lista del linux kernel.
      • Si vas a hacer una pregunta, antes de postear a la lista, trata de encontrar la respuesta en la documentación disponible o en los archivos de la lista. Solo recuerda que el 99% de las preguntas en la lista ya han sido respondidas por lo menos una vez. Usualmente la primer respuesta es la más detallada, por eso los archivos contienen mejor información de la que obtendrias de alguien de quien ha respondido la misma pregunta docenas de veces.
      • Se preciso, claro y conciso, cuando hagas una pregunta o haciendo comentario o anunciando u bug, posteando un parche o lo que sea. Postear hechos, evita opiniones.
      • Sé educado, no hay necesidad de ser vulgar. Evita usar expresiones que puedan interpretarse como agresivas por los otros participantes de la lista, aún si el asunto tratado es relevante para ti y/o controversial.
      • No entres en controversias. No trates de tener la ultima palabra. Eventualmente tendras la última palabra, pero esto significa que habras perdido todo el crédito de simpatía.
      • Una línea de código dice más que cien palabras. Si piensas una nueva característica, primerlo implementala, luego posteala en la lista para comentarios.
      • Es muy fácil criticar el código de alguien más, pero cuando escribes algo por primera vez, no es tan simple, si encuentras un bug, un error o algo que se pueda perfeccionar, no postees inmediatamente un comentario tal como "Esta parte de codigo es crap", Cóomo pudo incluirse en el kernel?". Contacta al autor del código, explicale el problema, y trata de obtener el punto de vista de forma simple y humilde. Haz eso pocas veces y obtendras muchos créditos como buen depurador de código. Entonces cuando TU escribas una parte de código las personas te prestaran atención.
      • No regañes a los principiantes que hacen preguntas incorrectas. Esto añade ruido a la lista. Enviales un mail privado apuntandolo a la fuente o información e.j. estas FAQ.
    • (MEA) Si posteas en HTML, tu email no llegaráa a la lista (mira la Sección 3.9).
    • (REG) No postees ningún material religioso o politico, incluyendo tu firma. Hacerlo en el cuerpo del mensaje enfadara a las personas, por que simpre esta fuera-de-tópico y es un desperdicio del ancho de banda recuerdo que aún en el siglo 21, muchas personas remember aun estan agobiadas por el segundo para el ancho de banda por sus ISP o telco o ambos).
      El Incluir este material no deseado en tu firma signature es menos obio, pero es más inutil (predicando para convertir). La mayor&iaacute;a de las personas la ignoraran, y muchas estaran gustosas de ignorar el contenido de tu mensaje, dandose cuenta que eres un bobo. Si quieres ser tomado en serio deja la caja del jabon en la casa. Limitate a postear problemas ténicos.
  14. Llega spam a la lista?
    • (ADB) No entrara más spam a la lista del linux-kernel, raramente veras un posteo comercial a la lista. OTOH una vez que has posteado a la lista, espera recibir unos pocos indeseables correos en los siguientes días. Desfortunadamente algunas personas miran la lista y creen que es buena idea escoger nombres de esta. Hay muchas formas de evitar el spam, mira los sitios dedicados anti-spam en la lista. Aprendí muchas cosas de esta forma.
    • (REW) Aunque los encargados de la lista hacen lo posible por mantener la lista libre de spam, es posible que esto no sea 100% efectivo en el volumen de la lista del linux-kernel. Pero ocasionalmente llegan. Por lo tanto necesitamos mantener la suscripció abierta para "todos". Algunas otras personas importantes tiene dos o tres direcciones de correo. Ellos también necesitan postear desde diferentes cuentas. Como consecuencia a algo que se ve como uns suscripción de una dirección de retorno válida tiende a estar en la lista. No hay nada automatizado en el sistema de filtrado que lo pueda hacer.
      El resultado final es un spam por mes. Eso pasa. Al encargado le llegaran abundantes correos spam y bloqueara los dominios de donde provienen. Por favor no molestes en la lista acerca de esto, no añadas ruido . No postees "This guy is a jerk if he spams this list". No postees "I traced him, you can mail bomb him at this address". Don't post "I traced him, bother his postmaster at such and such".
  15. No estoy recibiendo ningún mensaje más de la lista! esta caida o que?
    • (ADB) Majordomo es un servidor de listas de correo inteligente. Si por alguna razón tu dirección de email no esta disponible, despues de algunos reintentos, seras desuscrito automaticamente
    • (REW) Por otro lado, han ocurrido ciertos accidentes con el servidor de la lista de correo. Los cuales han rechazado la suscripción a la lista. Solo vuelve a suscribirte. Majordomo te hara llegar una nota diciendo que aún estas suscrito si accidentalmente fuiste desuscrito. NO postees "Esta es una prueba: esta funcionando la lista? hace dias que no recibo mails de la lista".
    • (MEA) Puedes conseguir ser desuscrito por que la retransmisión del tráfico de de los MTAs para obtener quejas por alguna razón. Lo primero es verificar que los datos enrutados a tu correo en el DNS sean validos, e.g. pon tu direeció en la caja de entrada en: http://vger.kernel.org/mxverify.html
    • (MEA) VGER y/o uno de sus buzones fanout puede estar sobrecargado. Usualmente los administradores del sistema notificaran la situación, y la solucionaran en 1-2 dias sin ninguna perdida de mensajes, pero n seguimos al mundo entero. Pide ayuda en postmaster@vger.kernel.org a ver si pudo despachar el problema. Pedir ayuda en la lista NO ayudara, el hacelo solo pone más carga en el sistema!
  16. Hay algún gateway NNTP en algún lugar para la lista de correo?
  17. Quiero postear una gran idea (tm) a la lista. Qu&eeacute debo hacer?
    • (REG) OK, eso es maravilloso. Ahora:
      • Primero, asegurate que tu idea es relevante para el desarrollo del kernel. Quizas tu idea podria estar mejor implementada en la librería C, o talvez en una nueva librería? Antes de postear a la lista del linux-kernel, asegurate de que realmente es un problema de kernel.
      • OK, entonces tienes esta maravillosa idea para el kernel. Estas seguro de que nadie antes lo ha pensado antes ? Leer todo este documentos es un buen punto para comenzar. También busca los archivos de la lista de correo para ver si antes ya se ha tocado ese tópico.
      • Ahora que has verificado que tienes una idea que nadie ha sugerido antes. Para una mejor respuesta, codifica una implementación/parche para el kernel y postealo a la lista cuando anuncies tu idea. Si provees código, puedes estar seguro de que alguien lo probara y te hara comentarios acerca de este mismo. Si no sabes nada acerca de kernel hacking, es buen momento para comenzar a aprender:-) Cuando hayas implementado tu idea, podras llamarte a ti mismo un Guru de Linux.
      • Si realmente no puedes codificar algo, pero aú te gustaría que tu idea sea implementada, postea un mensaje a la lista del linux-kernel. Se lo más claro posible, entonces las personas podran entender tu idea rapidamente. Si tienes suerte, alguien a quien le guste tu idea encuentre el tiempo para implementarla. Si nadie procede a implementarla , no tienes suerte:: recuerda, todos somos voluntarios y también tenemos muchas cosas que hacer.
      • Si obtienes respuesta negativa a tu idea, no te ofendas, despues de todo , todos tenemos diferentes puntos de vista acerca de que es una Buena Idea (tm) y una Mala Idea (tm). Si alguien es grosero contigo, por favor resiste la tentacion de armar una guerra en la lista. En vez, enviales un mail privado diciendole que no te gusta su groseria, se cuidadoso de no ser presionar demasiado.Si todos son educados, pero solo estan en total desacuerdo con tu idea, se cuidadoso de no presionar demasiado. Si la gente no ha entendido el punto que tratas de explicarles, trata de hacerlo de forma diferente. Pero si la gente entiende tu idea pero hace falta mantenerla, es hora de parar de presionar. Presionar más fuerte solo hara que te ignoren.
      • Si estas convencido que tienes la razón, a pesar de lo que los demas digan, para de hablar e implementalo! Si tienes la razón, tendras la ultima palabra.
    • (ADB) Buen código (explico. documentado, elegante, eficiente) y algunos datos de benchmarking mostraran que tu Gran Idea funciona bien mostrara de forma adecuada que tienes la razón.
  18. Hay un largo hilo acerca de algo completamente fuera de tópico, no relacionado con el kernel, y aún algunas de las personas que estan en la sección "Quién es quien" de estas FAQ estan mezclandose en esto. Qué debo hacer para evitar ese "ruido"?
    • (REW, ADB) Ignoralo.
    • (REG) No envies respuesta a la lista del kernel bajo ninguna circunstacia. Si te sientes obligado a responder, hazlo en correo privado informandole a la persona que el mensaje estuvo fuera de tópico. O configura un receptor procmail para que evite todos los mensajes para ese hilo: de esa forma nunca más miraras mensajes pertencientes a ese hilo.
  19. Podemos modificar la línea Subject: para ayudar a los filtros de mail?
    • (REG) La proposicióm que se antepone antes de la línea subject es [LINUX-KERNEL].
      Esta pregunta ha sido propuesta antes muchas veces, y la respuesta siempre ha sido "no" o "hay mejores formas de filtrar el correo". La mayor&iaacute;a de los desarrolladores, y todos (?) los encargados de la lista toman esta posición. Algunas de las razones son:
      • Esto incrementaria el tamaño de la línea Subject:. Esto es un problema, ya que limita la cantidad de información &uacte;til que puede verse en la línea Subject:, haciendola más difícil de buscar a través de una lista de lineas Subject; para buscar asuntos interesantes.
      • No funciona para mensajes cross-posted, ya que la línea de asunto para un correo cambiara dependiendo vía que lista fue enviado. Esto no solo puede confundir los filtros de recepción, de diseño simple, puede tambié romper a los lectores de correo lethreaded (las gente puede terminar leyendo el mismo mensaje dos veces).
      • La forma correcta de filtrar es basar tu buzón de entrada en la línea X-Mailing-List:, la cual deberia tener siempres "linux-kernel@vger.kernel.org".
      U ejemplo de buzón procmail se veria como este: 
      # Linux-kernel list
:0: /var/lib/emacs/lock/!home!fred!mfilter!linux!kernel
* ^X-Mailing-List:.*linux-kernel@vger\.kernel\.org
/home/fred/mfilter/linux/kernel
      Las Personas suscritas a linux-kernel-digest@lists.us.dell.com, el cual usa GNU Mailman, deberian tener algo como esto: 
      # linux-kernel-digest
:0
* ^X-BeenThere: linux-kernel-digest@lists\.us\.dell\.com
/home/fred/mfilter/linux/kernel-digest
      Los que usen otro agente de correo (mailagent) pueden tratar esto en su archivo .rules (gracias a Martin Smith <martin@sharrow.demon.co.uk>): 
      To CC: /linux-kernel@vger.kernel.org/
{ SPLIT -adi ~/Kernel }
      Similar que con procmail puedes omitir el directorio de mail desde el comando split. Esto causa que los mensajes separados sean devueltos a la cola del agente de correo para futuro procesamiento.

      La mayor&iaacute;a de mailers con capacidades de filtrado pueden configurarse de forma similar. Si no, entonces puedes simplemente instalar procmail. Si quizá estas corriendo un SO dañado que no puede filtrar apropiadamente, y no hay un por de procmail para esta, entonces también deberias actualizarlo, o aceptar que no seras capas de filtrar la lista del linux-kernel. No molestes con preguntas de puede haber modificaciones en la línea subject.

  20. Podemos tener un encabezado Reply-To: añadida al tráfico de la lista?
    • (DW) Algunas listas de correo añaden automaticamente un encabezado Reply-To: a los mails que van a través de ellas, forzando a la gente a contestar a la lista, mejor que responder personalmente al autor original del mensaje. Esta es una mala por muchas razones que no se nombraran aquí. Mira el excelente sumario de Chip Rosenthal Reply-To: Munging Considered Harmful para mayor explicación.
  21. Puedo postear ofertas/pedidos de trabajo a la lista?
    • (REG) Por supuesto que no! Esta es una lista de desarrollo técnico, no un intercambio de trabajo. Si quieres unirte a una lista de intercambio de trabajo, envia subscribe linuxjobs en el cuerpo del mensaje a: majordomo@eax.com ejecutando el siguiente comando:
      echo "subscribe linuxjobs" | mail majordomo@eax.com
      Para enviar mensajes, hazlo en un correo a linuxjobs@eax.com
  22. Por qué obtengo rebotes (bounces) cuando envio correo privado a algunas personas?
    • (REG) Esto podria ser por una variedad de razones, tales como problemas temporales con la entrega de correo. Tu email puede también estar bloqueado (permanentemente rechazado) individualmante por sus ISPs. Esto usualmente pasa si envias correo desde una máquina o dominio que este figure en las listas de MAPS RBL, DUL y ORBS. Estas listas se han establecido para proteger a las personas contra el spam. Mira http://www.mail-abuse.org/ y http://www.orbs.org/ para mayor información de esas listas.
      NOTESE que esas listas no tratan de bloquearte personalmente, tratan de bloquear a los spammers conocidos o a los sitios amigos del spam (RBL and ORBS), o usuarios dial-up descontrolados (DUL). Si te estan tratando de bloquear, probablemente significa que tienes la desgracia de estar usando un ISP que no es buen ciudadano de la red y por eso ha sido agregado a las listas RBL o ORBS. En algunos casos, puedes ser bloqueado por que tu ISP tiene voluntariado sus rangos de direcciones IP de dial-up a los DUL, en tal caso deberias usar su retransmisión de correo aprobado, en vez de enviar correos directamente desde tu host.
      NO debes enviarles mensajes a la lista del kernel acerca de esto, ya que la gente no pude y no te ayudara. No/O deberias usar la lista para obtener un mensaje de la persona a la cual tratas de contactar. Ese no es el propósito de la lista.
      Si intentas quedar como un tonto en público, sigue el mismo camino que otros antes que tu, y molesta a la lista del kernel acerca de cuan cerca estas de ser bloqueado a causa de que tu ISP. Espera simpatía de algunos, quejas de otros y silencio de la mayor&iaacute;a. La red ganara y tu podras aúm estar bloqueado por las listas anti-spam, muchas personas ignoraran mails futuros tuyos (por que has hecho de ti un tonto en público), y puedes figurar en los killfiles de algunas personas (explico. personalmente estas siendo bloqueado por que algunas personas estan cansados de ti y no quieren escuchar más de ti).
      Actualmente si quieres que tus correos no sean bloqueados más, haz que tu ISP corrija sus actos, o cambia a un ISP decente. Si requieres el uso de la retransmisió:n de correo de tu ISP, pero este no se mueve, quejate ante tu ISP o cambia a uno competente.
      Si tu ISP no te responde y no tienes un ISP alternativo, solo tendras que acceptar que formas parte de una creciente lista de personas las cuales bloquearan tus correos (mientras más y más personas se suscriban a las listas anti-spam). No tiene sentido callar a las personas que se estan defendiendo en contra del spam (nadie esta obligado a recibir todos y cada uno de los correos), en vez ve a la lista de la peste de los spammers.

Sección 4 - Preguntas "Cómo hago?"

  1. Cóomo posteo un parche?
    • (ADB) Asumo que hiciste el parche siguiendo las instrucciones generales que se encuentran arriba. Ahora escribe un corto post describiendo tu parche, la versión del kernel para la cual se aplica, tus pruebas, la retroalimentación que quieres recibir, etc. Eso deberia alcanzar en 10 lineas. Adjunta tu parche y en una línea README el archivo readme describiendolo muy consisamente, y mencionando tu nombre y tu correo (ambos como archivos ASCII o como tarball codificado MIME). En el asunto de tu post, escribe: [PATCH] <el nombre del driver o pieza de código parchado>, kernel < versión del kernel >. Envialo. Espera.
      El pequeño archivo README asegura que tu parche no empezara a rodar en la red sin notificar tu nombre. Si no te importa el copyright y/o tu parche es trivial, puedes saltar el paso de entarrar (tar) los archivos, solo aplicale gzip al archivo parche y adjuntalo a tu post.
    • (PG) Si tu parche es de gran tamaño (digamos mayor de 500 lineas) considera postear una URL apuntando al parche solo, con su descripción, en vez del parche entero. Si no tienes un sitio a mano WWW para poner el parche, entonces por lo menos comprimelo con gzip antes de adjuntarlo a la descripción de posteo/parche.
    • (REG) Notese que Linus no lee mucho la lista del linux-kernel. Entonces si quieres que el vea un parche, necesitas enviarselo directamente (dicelo poniendole Cc: a el si posteas a al lista). Notese que a Linus le gusta ser capaz de leer parches en ASCII plano, por eso cualquier cosa que este uuencoded o MIMEd es como ir al bit-bucket. Si solo enviaste una URL por que tu parche es grande, enviala una copia en texto-plano a Linus privadamente.
      Tambiém que Linus abandona los parches silenciosamente cuando esta demasiado ocupado (lo cual es siempre:-), entonces entonces si no ves tu parche en el próximo parche del kernel, enviaselo de nuevo. Oh, y no esperes que el te diga que ha aplicado el parche.
  2. Cómo capturo un Oops?
    • (REG, citando a Keith Owens) Si un Oops es recuperable entonces el texto primero aparece en el buffer de mensajes del kernel (/proc/kmsg). Puedes usar el comando dmesg para imprimir los contenidos pero la mayoría del tiempo klogd y syslogd capturaran el Oops y lo escribiran en tus archivos de log.

      A veces un Oops es tan grave que el kernel esta completamente colgado. Cuando ocurre esto, casi todo lo que requiere soporte del kernel también esta muerto. En particular la mayoría de los subsistemas interrupt driven no son usables, especialmente despues del terrible mensaje "Aiee, killing interrupt handler ". Desde que la mayoría de controladores de disco usan interrupciones, no es posible la E/S por eso el Oops no se escribe en los logs. El mismo problema se aplica a al logging a través de la red, la mayoría de tarjetas de red requieren el manejador de interrupciones.

      En un completo cuelge, tienes tres opciones.

      • Escribir el Oops a mano desde la pantalla y teclearlo en el computador despues que haber reiniciado. Esta es la única opci&ocute;n si no tienes planeado un cuelgue del kernel.
      • Si lo planeas, adelante ve e instala una consola serial enlazada a otra máquina (lee linux/Documentation/serial-console.txt) entonces podras capturar el reporte de Oops en la otra máquina. Esta es la más fácil y confiable opción.
      • Desde el kernel 2.3.10 es posible usar el puerto paralelo como consola. También puedes conectar una impresora real, u otro computador con soporte EPP (Enhanced Parallel Port) Puerto Paralelo Extendido, el cual prentende ser una impresora.
      • Han habido parches en la lista del linux-kernel para guardar el log en algún en el hardware. Desafortunadamente esos parches son muy específicos del hardware. Busca los archivos del l-k (linux-kernel) por "Oops asistido", "OOPS output over reboot" y "KMSGDUMP". La mayoría de esos parches requiren que el teclado aún funcione y aú que sea inutil cuando el kernel se cuelgue.
      Otros sistemas operativos pueden guardar el log aú cuando la máquina se cuelgue, Por que no Linux? Cualquier SO que puede guardar el log despues de una falla catastrofica de kernel debe hacerlo sin soporte del kernel, eso tipicamente significa que usa el hardware underlying. Alas el hardware ix86 no provee soporte suficiente para esto, en particular la mayoría de las BIOS limpiaran la memoria al reiniciar, destruyendo cualquier dato almacenado.
  3. Cómo posteo un Oops?
    • (ADB) Asumiendo que has encontrado Oops genuino (son raros hoy en día, pero ocurren), debes postear las partes relevantes del log de tu sistema, archivo de configuración del kernel y el mapa de símbolos del kernel, ademas de una descripción de tu hardware y bajo que circustancias occurrio Oops. Can the Oops be triggered by any particular method? Ocurrio despues de que cambiaste alguna parte la configuración de tu hardware?
      No postees tu reporte de oops antes de que leas linux/Documentation/oops-tracing.txt, las partes importante estan en linux/README, el programa en C ksymoops en linux/scripts/ksymoops el cual tiene otro README, y las páginas man e info de gdb (gracias a Paul Kimoto por este consejo). Estos documentos describen el procedimiento básico para seguimiento de oops del kenel. Buena información de seguimiento (trace) hace más fácil para entender y solucionar aparentemente esos raros oopses.
    • (REG) No postees un Oops si no has ejecutado ksymoops para decodificar las direcciones de los símbolos. El reporte sera ignorado por que contiene muy poca información &uacte;til.
      Asegurate que copias el archivo System.map correcto en el directorio /boot o en el directorio de los modulos, de otra forma obtendras resultados incorrectos.
    • (REG, citando al "The Doctor What") Hay algunas situaciones que hacen inutil un oops del kernel. Las dos razones más obias son si estas overclocking tu CPU o ejecutando vmmon de VMWARE. La razón es que el overclocking puede introducir errores aleatorios de bits, mientras el vmmon de VMWARE tiene la habilidad de (y lo hace) cambiar partes del kernel. En ambos casos, los datos del kernel, reportados por el oops, no seran utiles.
  4. Creo que encontre un bug, cómo lo reporto?
    • (ADB) Actualmente un bug difiere levemente de un oops. Un oops ocurre cuando el kernel detecta que algo dejo de funcionar. Un bug ocurre cuando algo (presumiblemente, en el kernel) no se comporta en la forma que deberia, también en un driver o en un algún algoritmo del kernel. Si puedes detectar ese comportamiento inadecuado, puedes o no obtener un oops.
      Quizás el paso más importante para determinar bajo que condiciones se puede trigger el mal comportamiento, si es reproducible.
  5. Qué información deberia ir en un reporte de bug?
    • (ADB) Afecta esto la seguridad del sistema? Esta esto relacionado con alguna configuración especifíca de driver/hardware? Did you manage to identify the piece(s) of kernel código concerned? Esto realemente depende del tipo de bug que encuentres.
      De hecho Frowahlt Egerer ha propouesto un reporte de bug estandar para el Linux kernel (mira las anteriores FAQ, apéndice B) que es lo mejor que puedes conseguir (pero desafortunadamente se usa raramente).
    • (TYT) Por favor sigue esta adecuada guía de como reportar un bug: recuerda, los desarrolladores no tienen acceso a tu sistema, y no pueden leerte la mente. Dinos que versión, de kernel usas y que hardware tienes (si no estas seguro, mayor detalle es mejor que menos). Por lo menos, que procesador y que motherboard tienes, cuanta memoria, cuantos y que tipo de discos (IDE, SCSI, etc.), que tipo de controlador de disco, que otras bus de expansion usas (especifica si son PCI o ISA o algún otro bus). Útil también : qué versión de gcc y binutils se usaron para compilar el kernel.
      Para encontrar una forma simple, y confiable de visualizar el problema. Diciendole al desarrollador que tiene que configurar algún entorno de aplicaci&oacu