Tráfico del Núcleo #121 For 11 Jun 2001

Realmente deberían ser Linux y/o Alan quienes respondieran esto, pero de mis propias observaciones, esta es la forma en que pienso que va:

Alan y Linus no siempre coinciden en lo que debe ir en el núcleo; y aún cuando lo hicieran, a veces no coinciden en cuándo algo está listo para ser incluído. Alan puede pensar que un conjunto particular de parches está listo, mientras Linus piensa que necesitan madurar un poco más; o tal vez él piensa que toda la aproximación está mal y debe ser desechada. Así que Alan lo pone en su núcleo, y Linus lo deja fuera del suyo. (Por supuesto, a veces es Linus quien agrega algo que Alan rechaza.) A veces sucede que una de esas nuevas ideas resulta mejor de lo esperado (especialmente después de pasar a través de unos cuantos ciclos de reportes de bug/nuevos parches), y la persona que la rechazó cambia de parecer y después la incluye; o tal vez no funciona y también es desechada. Además, como ya habrás observado, con regularidad Alan resincroniza la mayor parte de su árbol con el de Linus así que no se apartan tanto, y Linus ocasionalmente hace lo mismo.

Solía molestarme, también, tener que mantenerme al día con dos árboles del núcleo diferentes. Pero me he dado cuenta que es una Cosa Buena. Provee una forma para que la gente con diferentes puntos de vista se aproximen a una idea desde más de una dirección. Si los dos núcleos están tratando de resolver un problema particular de diferentes formas, podemos ver cómo cada aproximación trabaja en el mundo real, en lugar de solamente en una discusión teórica. Si los dos núcleos se ramificaran demasiado separados podría ser un problema, pero Linus y Alan han sido diligentes para evitar que esto suceda. Pienso que el juego entre ellos (¿la palabra "competencia" es muy fuerte?) entre las dos ramas ha ayudado a hacer al núcleo "oficial" mejor que como lo hubiera sido de otra manera.

Bueno comenzó por accidente pero se ha vuelto bueno tener un árbol en donde se mezclan los cambios, probado por aquellos que necesitan las composturas y revisiones de terceras partes antes de que vayan a Linus.

Así que el árbol -ac es un tipo de revisión entre colegas, prueba y proceso de destilación para los parches.

• Nueva opción de montado show_sys_files=<bool> para mostrar todos los ficheros de sistema como ficheros normales.
• Soporte para los ficheros y en general para cualquier atributo hasta el tamaño máximo de 2TiB soportado por el sistema de fichero NTFS. Note que sólo damos soporte a inodos/clusters de hasta 32-bits inclusive en este punto.
• Soporte para las listas de corrido de tamaño mayor a 128kiB (usando vmalloc_32() en lugar de kmalloc()).
• Se compusieron condiciones de carrera en el alojamiento de registros de clusters y grabaciones mft.
• Se compusieron bugs mayores en los atributos manejo /búsqueda / comparación.
• Se compusieron bugs mayores en la compresión de una lista de ejecución en una matriz de pares ordenados.
• Se compusieron bugs mayores en el alojamiento de nodos-i, En particular en la creación de ficheros y en mkdir.
• Se compusieron fugas en memoria.
• Se compuso un bug mayor en la asignación de disposición de los nodo-i de números secuenciales.
• Muchas otras composturas de bugs que no recuerdo ahora...
• Compuesto un bug NULL encontrado por el revisor Stanford en ntfs_dupuni2map().
• Conversión de una variable de pila grande a una dinámicamente alojada en ntfs_get_free_cluster_count() (encontrado por el revisor Stanford).
• Nuevo esquema de versiones ya que estaba muy confundido con el esquema basado en fecha... (las versiones previas a esto son sólo internas, nunca han sido liberadas al público, así que no se extrañarán los números antes de 1.1.15).

• No usar el controlador para escribir ya que corrompe el sistema de ficheros. Si lo usa, obtenga las herramientas Linux-NTFS y use la utilidad ntfsfix después de desmontar una partición en la cual escribió.
• Usar "ls -l" en lugar de solamente "ls", de otra manera la última entrada en el directorio no se muestra para algunos directorios. (?!?)
• Usar la opción de montaje show_sys_files la cual generalmente debería hacer que las cosas funcionen mejor. (Resulta que se muestran tanto los nombres de ficheros cortos y largos como los ficheros de sistema.)
• Los caracteres especiales no son tratados correctamente. Por ejemplo si el nombre de fichero contiene una apóstrofe no será capaz de abrirlo.
• La escritura de registros de extensión no tiene soporte adecuado.

El gran problema con VIA no es que su hardware tiene bugs. Todos tiene bugs. Puedo tener un problema con un conjunto de chips intel ir a developer.intel.com y generalmente obtener una respuesta directa y muchas veces una solución temporal. Esto me hace feliz. El problema no es el bug, es no dar información honesta sobre el mismo.

Si VIA tuviera erratas públicas que dijeran cosas como 'Las ráfagas de prefetch pueden causar problemas a menos que actives el bit 3 de blah' nosotros bien podríamos ser capaces de evaluar los impactos en el rendimiento y la gente haría soluciones sensibles y tendríamos código confiable.

Intel no es perfecto de cualquier forma. Tenemos una pila entera de laptops que se caen cuando speedstep activa una trampa que no podemos manejar. Tenemos un problema de APIC que tomó mucho esfuerzo porque se negaron a ayudarnos.

Cuando los vendedores ayudan la vida se vuelve mucho más fácil. El USB de AMD fue un problema debido a la errata. Una vez que publicaron las composturas el USB de AMD dejó de ser un problema.

Parece que el problema es causado por algún bug relacionado con DMA en el conjunto de chip VIA y/o en en el controlador VIA DMA-IDE de Linux. Finalmente me deshice de los congelamientos simplemente al compilar el núcleo completamente sin soporte IDE-DMA. Ahora hdparm muestra discos que no usan DMA y el sistema es estable, hasta donde puedo decir ahora.

Lo he probado MUY intensivamente en los últimos días y no he logrado congelarlo. Por 12 horas un grupo de procesos concurrentes copiaron gigas de datos sobre todos los discos, calcularon criptografía intensiva en CPU etc, y el sistema no se ha congelado. Con propósitos de depuración también intenté bajar a 2.2.19 con IDE-DMA activado. Se cayó. Así que realmente parece que el problema aquí es DMA.

En BSD, select() establece que cuando un tiempo de espera expira, los bits pasados a select no serán alterados. En Linux, que en la página de manual proclama cumplir con BSD en este aspecto (pero no establece de ninguna forma que sucederá a los bits), establece a cero las máscaras de bits de los usuarios cuando un tiempo de espera expira. He escrito un caso de prueba, y corre en ambos sistemas; BSD se comporta como está establecido, Linux no actúa como BSD.

¿Las páginas de manual deben cambiarse para reflejar la realidad, o select componerse para actuar como BSD?

Hace algunas semanas le prometí a Jeff Garzik escribir una parte de documentación de procfs, así que aquí está. Esta guía está escrita en DocBook SGML y dice cómo usar el procfs desde el núcleo.

Aún estoy buscando una forma adecuada de incluir automáticamente el código de ejemplo en el fichero SGML, este parche con el mismo contenido en dos ficheros es un hack un poco feo.

El parche es en contra de linux-2.4.5, pero debe aplicarse limpiamente también contra 2.4.5-ac*.

Eso es correcto, yo solo lo envié para incluirlo en el núcleo, así que no está ahí aún. Tan sólo parcha tu código del núcleo con mi parche, ejecuta "make psdocs" y lo tendrás también en tu árbol del núcleo.

De cualquier forma, como tenemos una pregunta similar de procfs en la lista kernelnewbies, ya puse en línea las versiones html y pdf en las páginas de documentación de kernelnewbies:

http://www.kernelnewbies.org/documents/kdoc/procfs-guide/lkprocfsguide.html

Me da gran placer anunciar que el fichero maestro Configure.help está completo con respecto a 2.4.5. Cada uno de los 2699 símbolos de configuración usados actualmente en los ficheros de código en C de la base de 2.4.5 o de los Makefiles ahora tienen una entrada en Configure.help.

Esto no, por supuesto, significa que el trabajo de mantener a Configure.help está hecho; los símbolos se agregarán y descartarán en el futuro (hay una nueva variedad en ac5, ahora todos documentados), y algunas entradas existentes podrían ser reescritas y expandidas. Pero hemos pasado un momento clave -- el mantenimiento será ahora un asunto de mantener el barco a flote en lugar de tratar de ignorar un agujero en el costado.

Gracias a todos los contribuyentes que ayudaron a juntar las cerca de 550 entradas necesarias para estar al corriente, demasiados para nombrar aquí. El resultado está disponible en:

http://www.tuxedo.org/~esr/cml2/Configure.help.gz

Aunque es parte de la página del proyecto CML2, puede ser usado con CML1 y es actual con respecto a los árboles tanto de Linus como el de Alan.

Ahora tengo dos peticiones para Linus y Alan:

1. Por favor tomen este trabajo ahora. Es una mejora realmente sustancial con respecto a lo que tienen en sus árboles, el incorporarlo no puede romper nada, y ayudarán a prevenir futuras disputas debido a parches en conflicto en el futuro.
2. Por favor hagan una política de rechazar parches que agregen nuevos símbolos de configuración sin añadir también una entrada explicativa en Configure.help -- y por favor *anuncien* que lo harán. Podemos elevar nuestros estándares ahora, y con el fin de tener un núcleo y un sistema de configuración bien documentados yo propongo que deberíamos.

En mi humilde opinión, un procfs debería ser para información de procesos, nada más. El procfs en su forma actual, aunque es útil, es algo horrible que debería ser sacado al patio trasero y balaceado usando grandes cartuchos.

Ehrmmm. No, pero en serio, las cosas que no son de procesos deben ser separadas de procfs. Tal vez llamarlo kernfs o lo que sea.

No coincido con aquéllos que claman que 2.4.xx es malo o aún beta.

Nosotros los administradores tenemos la responsabilidad de probar los primeros núcleos y enviar buenos reportes de bugs para que los desarrolladores puedan resolver los bugs. Esta es la forma en que podemos contribuir a la comunidad.

Pero es realmente riesgoso usar estos núcleos en servidores PRINCIPALES de producción 24x7.

Esto ha sido cierto para 1.2.x 2.0.x (Pienso que fue la mejor serie de núcleos linux) 2.2.x y 2.4.x y será también para 2.6.x

Dado que sabemos que el soporte de los desarrolladores de código abierto son claramente mejores que los contratos comerciales de soporte, no veo la razón para quejarse acerca del trabajo de esos maravillosos hackers que gastan su tiempo libre programando para todos nosotros.

Estoy forzado a coincidir. Tengo 2.4.x en producción limitada, y con la excepción de los asuntos fatales de HP/APIC que tienen una solución temporal de "noapic" no he tenido problema alguno con ninguno de los núcleos 2.4.x que he usado.

Por definición el software abierto nunca alcanzará el tipo de estabilidad monolítica que requiere de años de congelamiento de código. Linux (especialmente 2.4.x) ofrece demasiado de regreso, y siempre puedo correr un núcleo 2.2.x. Diría que la estabilidad del núcleo ha sido *superior* a mis expectativas, francamente, considerando todo lo que ha cambiado.

Definitivamente es nuestra responsabilidad como administradores probar estos núcleos. Estuve corriendo 2.4.0-test1 la segunda vez que fue liberado, y el problema que he encontrado ha sido reportado e investigado (aparentemente es uno fuerte).

Tanto como MV, nunca he tenido los problemas severos que algunos han reportado. Eso no significa que no sea un problema, pero definitivamente indica que no es un aguafiestas global. Para aplicaciones intensivas en MV, saco a rodar un núcleo 2.2.19 como una medida preventiva mientras espero que el código de MV sea ajustado. Creo que habría esperado estas quejas durante la fase de -test. No sin mencionar que las distribuciones parecen haber sacado a rodar a 2.4.x bastante bien.

Las notas de Linus 2.4.0 son bastant claras en cuanto a que necesitas al menos el doble de RAM para intercambio con 2.4.

Marcelo está trabajando para cambiar esto pero ahora estás corriendo algo que se explicó explícitamente que no va a funcionar como quieres