Tráfico del Núcleo #116 For 30 Apr 2001

There were 518 different contributors. 262 posted more than once. 185 posted last week too.

Michael Reinelt reportó que su tarjeta PCI con el chip NetMos había funcionado hasta 2.4.3, con un parche particular que él había enviado a los mantenedores de puerto serie y de PCI. Con 2.4.3, encontró que sólo podía hacer que funcionara o el puerto paralelo o el puerto serie de la tarjeta, pero no ambos, dependiendo de cuál controlador (paralelo o serie) fuera cargado primero en el núcleo. Michael rastreó el problema en la función pci_announce_device() en pci.c, la cual sólo sería llamada si ningún otro controlador reclamaba un dispositivo dado. Ya que la tarjeta se mostró en el bus PCI como un solo dispositivo, sólo el primer controlador cargado lo vería. Agregó, "Temo que esto no sea un bug, sino un problema de diseño, y que será difícil de resolver. ¿Tal vez necesitamos una bandera para tales dispositivos que permita que sean reclamados por más de un controlador?"

Difícil. La especificación PCI tiene una forma perfectamente adecuada para manejar esto, teniendo subfunciones en el mismo chip. El diseñador de este chip en particular fue perezoso o algo, y no lo hizo en la forma adecuada. Lo cual significa que no puedes, y no debes, usar un controlador PCI genérico para el chip. Porque no se muestra como dispositivos separados para las funciones separadas.

Ahora, eso no significa que no puedes usar la tarjeta, o los controladores existentes. Sólo significa que debes componer el daño cerebral total del hardware.

Sólo significa que probablemente debes acercarte a él como un "puente PCI invisible" especial, y básicamente tener un controlador específico para ese chip que actúe como un controlador de _puente_.

Escribir un controlador de puente no es tan difícil: tu rutina de inicio instanciará los dispositivos detrás del puente (pe alojarías dos estructuras "struct pci_device" y las agregarías detrás del "puente", y harías que _ésos_ se vieran como dispositivos en serie y paralelos reales.

Ve por ejemplo drivers/pcmcia/cardbus.c: cb_alloc() para ver cómo crear un "pci_dev" nuevo (vee el ciclo "for i = 0; i < fn ; i++)": crea los dispositivos para cada subfunción encontrada tras el puente del bus de tarjeta. Realmente se reduce a "dev = kmalloc(); initialize_dev(dev); pci_insert_dev(dev, bus);").

Punto en el cual puedes usar felizmente los controladores actuales sin ninguna modificación.

Jeff Garzik elogió esta solución, pero advirtió, "esa es una pendiente resbalosa... Si haces eso como una solución para dispositivos multifunción, también tienes que considerar hardware aún más estúpido que exporta una función PCI, pero BARs múltiples para propósitos diferentes..."

En otro lugar, Gerard Roudier escupió sobre los creadores de la tarjeta de Michael, diciendo, "Un dispositivo PCI de una sola función que provee varias funcionalidades manejadas comúnmente por subsistemas separados, es nada más que una bolsa de mierda que no quisieramos dar soporte en ningún S/O en mi opinión. Déjenme clamar que los ingenieros que quieren que los S/Os den soporte a tal hardware son idiotas o bastardos." Pero Brian Gerst señaló, "Desafortunadamente, Windoze soporta esa configuración, y esto es suficiente para casi todos los diseñadores de hardware. Esto también es un problema con los puertos de la palanca de juegos en muchas tarjetas de sonido PCI."

En otro lado, Jeff preguntó en dónde estaba el parche de Michael, ya que él nunca lo había visto. Michael replicó que lo había enviado a Jens Maurer, Theodore Y. Ts'o, y a Tim Waugh; y Tim dió un vínculo a él en su página.

Steve Modica y otros han encontrado que la tarjeta Acenic para la tarjeta 3COM gigabit ethernet no habilitaba DMAs de 64-bit. Steve dijo que Jes Sorensen había sugerido la creación de una función pci_enable_dma64(), y tan sólo hacer que el controlador llamara a esa función en lugar de establecer la variable dma_mask a mano, como algunos controladores ya lo hacían. Agregó que usar una función tendría el beneficio adicional de ayudar a depurar situaciones en las que los controladores intentaran habilitar DMAs de 64-bit en buses que no son 64-bit. Jeff Garzik replicó que la función pci_set_dma_mask() ya existía, y que nadie debía más establecer directamente la variable, sino que siempre debía pasar a través de esa función. Pero Jes replicó:

Hmmm, me preguntaba si podríamos salir con una forma bonita de hacer esto en cajas de 32 bit que quieren activar DMA higmem. Justo ahora pci_set_dma_mask() quiere una dma_addr_t lo cual significa que tienes que hacer #ifdef CONFIG_HIGHMEM <bla> #else <ble> #endif.

¿Sería mejor introducir una función nueva que toma banderas de bit como argumentos?

Alan Cox pensó que esto estaría bien, y señaló una forma para tomar en cuenta a arquitecturas que no son 64 bit al mismo tiempo. Todos parecieron estar de acuerdo y se fueron a escribir código.

Alan Cox anunció 2.4.3-ac7, y Chris Meadors preguntó acerca de una compostura de APCI que había estado flotando por ahí. Alan replicó, "Pregunta a Andrew Grover. Yo no sigo los hilos de discusión de ACPI. He intentado usar ACPI en Linux y en otros SO's y me rendí. Agregar un intérprete hinchado para un lenguaje obscuro y mal diseñado de descripción de hardware bios simplemente no es mi idea de progreso. Es una manera extremadamente complicada de Intel para tratar y mantener cosas propietarias como speedstep, nada más." Andrew Grover también replicó a Chris, diciendo que él estaría enviando un gran parche ACPI a Alan y a Linus Torvalds pronto.

Eric S. Raymond anunció CML2 versión 1.1.3 en la página inicial de CML2. Dijo que esta versión sólo incluía composturas de bugs y limpieza de IU. Marko Kreen dió una buena reseña, diciendo, "Debo decir que las versiones 1.1.2, 1.1.3 son mucho más rápidas que las previas, realmente no puedo decir que CML2 es en alguna forma inusable para mí. ¡Buen trabajo!" en otro lugar, hubo algo de discusión sobre las elecciones de color de Eric para xconfig. John Cowan sugirío que ninguna opción de color sería adecuada para cualquiera, y que Eric tan sólo debía tomar los colores del .Xdefaults del sistema. James Rich coincidió, diciendo, "Sí, ciertamente esto tiene que ser hecho. Deben ser usado valores por omisión sensibles (y pienso que podríamos estar en ese punto) y después usar .Xdefaults (.Xresources o lo que sea) para permitir supediciones del sitio. Y realmente pienso que sea .Xdefaults y no .xconfigrc o algo así. Ya tengo suficientes .ficheros y me gusta la sintaxis de .Xdefaults." Pero Eric sintió que esto llevaría a inflación, ya que no había una biblioteca Python existente para decodificar el formato de .Xdefaults. John Cowan replicó que al menos, los colores no deberían estar fijos en el sistema. Algún mecanismo era necesario para configuración del usuario, sintió. Bastante cerca, Peter Samuelson señaló, "Pensé que sólo estabas usando ligaduras de Python para Tk. ¿Nos estás diciendo que la biblioteca Tk, que por 8 o 10 años han sido *el* conjunto de toolkit/widget X para crear guiones, no incluye una interfaz para recursos de X?" Eric replicó que no había visto una cosa así documentada en ningún lado, pero Andrew Pimlott y Olaf Titz le indicaron el comando 'option' en Tcl/Tk.

El proyecto Linux GFX creció de la necesidad de un servidor X de mayor desempeño que tenga un ciclo de desarrollo mucho más rápido. En los últimos años las tarjetas gráficas y los ambientes multimedia han crecido a tal tasa que las soluciones X actuales no pueden mantener el ritmo ni se enfocan en producir servidores X de alto desempeño específicamente para linux. También la comunidad ha solicitado funcionalidad específica que nunca ha salido a la luz.

Este proyecto busca empezar de cero para desarrollar un nuevo ambiente X que solucione estos problemas. Lo he publicado aquí porque solucionaremos varios asuntos acerca de la administración de hardware entre el núcleo y el ambiente X window. Por supuesto el ambiente X es extremadamente amplio así que esto requerirá habilidades de varias áreas así como muchos programadores. Así que será bienvenido cualquiera que quiera ver una alternativa a la implementación X actual. Si quieren suscribirse a nuestra lista de correo tan sólo sigan el vínculo a continuación. Gracias.

http://lists.sourceforge.net/lists/listinfo/linuxgfx-dev

David S. Miller le dijo a James que no desperdiciara su tiempo. Dijo, "El árbol X, sus protocolos asociados y APIs, son lo suficientemente complicados tal cual como son, y el proyecto xfree86 tiene algunas de las gentes más talentosas y capaces en esta área. Sería un paso hacia atrás hacer cosas fuera del desarrollo de xfree86. Si el asunto es que "las cosas no suceden lo suficientemente rápido en el árbol xfree86", ¿por qué no les echas una mano y les envías parches en lugar de quejarte?" Miles Lane coincidió, y agregó a James, "el impedimento principal para que XFree86 de soporte realmente bueno a la aceleración para un amplia variedad de hardware es la falta de documentación técnica de los fabricantes. A menos que planees lograr que los fabricantes de hardware te tengan desarrollando sus controladores de código cerrado para ellos, no veo cómo serás capaz de hacer algo mejor que lo que ya está haciendo la organización XFree86."

En otro lugar, Larry McVoy dijo que la última cosa que la comunidad de software libre necesitaba era otro proyecto. Dijo, "Lo que el mundo necesita es gente que se arremangue y haga trabajo real. Bien puedes ser uno de ellos, eso sería cool. Pero lo que sería aún más cool es si nos unimos juntos en esfuerzos reales, existentes y trabajar con ellos en lugar de sólo constantemente hacer un proyecto nuevo. Sí, es mucho más difícil, tienes que poner por lo menos parte de tu ego a un lado y aceptar el liderazgo de alguien más, pero se hacen más cosas de esa forma." Richard Gooch replicó, "Componer la corrupción de NFS sería un buen proyecto para trabajar en él. A pesar de años de golpearse en este problema, la comunidad aún tiene que componerlo."

Después, James replicó a la conversación en general, diciendo, "Gracias. Es verdad que todo lo que quiero hacer es ayudar a la comunidad. Siento al igual que mucha gente lo hace que XFree86 no puede satisfacer las necesidades de la comunidad. Es muy triste que la gente sienta que ninguna cantidad de gente en la comunidad de código abierto pueda hacer código de la misma o mejor calidad que XFree86 en un periodo de tiempo más corto. No lo siento de esa manera. Ahora saldré a trabajar en el código y la documentación para el proyecto. Gracias."

Daniel Phillips bloqueó su cerebro en la Fuente Verdadera, para descubrir porqué el borrado de un millón de ficheros tomaba cuatro veces más que crearlos. Emergiendo de su embelesamiento, dijo, "Es sencillo. Sigue de observar que actualmente hay mucho más espacio de disco dedicado a los nodos-i de un directorio que a las entradas de directorio en sí mismas, algo como 6 veces más. Los nodos-i se agrupan juntos 32 por bloque (bloques de 4K). Con directorios realmente grandes no todos los bloques de nodos-i pueden entrar en caché. Ahora, si borras ficheros en orden aleatorio muchos de los bloques de nodos-i estarán en caché con algunos, pero no todos, los nodos-i en ellos borrados. Algunos de estos bloques se escogerán para escribirlos para hacer espacio para los nuevos bloques que tengan que ser actualizados, y tendrán que ser leidos de nuevo para borrar el resto de los nodos-i en ellos." Probó esto en la práctica con algo de código incluido en su mensaje, y propuso varias soluciones posibles. Hubo un poco de discusión, pero nada conclusivo salió de eso.

Wayne Brown preguntó acerca del estado del soporte a escritura para el sistema de ficheros NTFS. Para más sobre esto, vea BROKEN KCREF. Anton Altaparmakov replicó, "Es extremadamente peligroso. Nunca lo uses a menos que estés desesperado. Crea ficheros corruptos y especialmente directorios. Tampoco puede borrrarlos (no está implementado). - Si escribes tienes que correr la utilidad ntfsfix en la partición después de umount antes de reiniciar en Windows el cual dejará que corra chkdsk en el siguiente reinicio que deberá componer todos los problemas creados por el controlador. - ntfsfix es parte del proyecto Linux-NTFS. Puedes descargar el código/rpm de código fuente o rpm pre-compilado de http://sourceforge.net/projects/linux-ntfs/" . Sugirió usar FAT32 en lugar de NTFS. Lee Leahu preguntó qué estaban haciendo los desarrolladores para hacer que el soporte de escritura a NTFS funcione, y Joanne Dow replicó, "Lo que entiendo de esta situación es que la escritura a un volumen NTFS no está aún 100% garantizado que destruya la estructura de directorios del disco. MS lo muta más rápido que lo que la gente puede aplicarle ingeniería reversa en una manera "limpia" y adecuada. La persona que había estado trabajando en este problema tenía acceso a información de MS para dar soporte de algunos otros productos. MS lo regañó acerca del soporte a NTFS. Así que él ha cedido tales materiales que tiene en lugar de continuar con el soporte de productos MS y está concentrándose en Linux. Pero hasta que su NDA termine él no puede trabajar en el código NTFS. Otras personas han tomado la estafeta. Pero como lo noté MS muta a NTFS rápidamente de forma notable así que yo no buscaría soporte para NTFS en el futuro cercano." Doug McNaught también replicó a Lee, diciendo, "Es peligroso porque NTFS es un formato propietario, y las reglas completas para actualizarlo (incluyendo jornadas etc) son sólo conocidas para Microsoft y para aquéllos que han firmado NDAs de Microsoft. Si lo actualizas incorrectamente se corromperá y perderás datos. Ciertamente es posible hacer ingeniería reversa de esas reglas, pero es muy difícil y consume tiempo."

Quien quiera que removió WRITERAW ha descompuesto NWFS. Las peticiones WRITE llaman a _refile_buffer() después de la petición de E/S y toman las cabezas de mi buffer creado localmente y las mezcla de regreso al caché de buffer de linux, causando corrupción masiva de memoria en el sistema. Esos buffers no pertenecen al caché de buffer de Linus, son propiedad de mi LRU y ll_rw_block no debería archivarlos ciegamente de vuelta al caché de buffer.

Por favor pongan algo de regreso para permitirme escribir sin que las cabezas de buffer siempre sean archivadas de nuevo en el caché de buffer de Linus. Esto ha descompuesto NWFS en 2.4.3 y superior.

Con respecto a usar el caché de buffer de Linus, hasta que pongan la capacidad de crear mapeo lógico de bloques en lugar de físico, no seré capaz de usarlo. Afortunadamente, esto entrará en 2.5. Tengo a algunas gentes tratando de usar esto con 2.4.3 y están muertos en el agua hasta que esto se solucione.

Jens Axboe publicó una forma para que Jeff hiciera sus escrituras como las quería, usando la siguiente construcción:

Mientras el despliegue de ECN se incrementa, la gente está notando en incremento que algunos sitios web claves son aún inaccesibles cuando ECN está habilitado.

Un sitio Web ha sido creado para apoyar con esta transición, con dos características claves: (1) se publican composturas relacionadas con ECN en esta página Web, y (2) se publican los vendedores cuyos productos están descompuestos en esta página Web.

La dirección es http://gtf.org/garzik/ecn/

Drew Bertola agregó, "La página de Sally Floyd sobre Notificación Explicita de Congestión en TCP/IP. http://www.aciri.org/floyd/ecn.html"


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	7 Apr 2001 - 19 Apr 2001	(47 posts)	Dispositivo PCI Multifunción
2.	12 Apr 2001 - 18 Apr 2001	(8 posts)	Habilitando DMAs De 64-Bit
3.	16 Apr 2001 - 19 Apr 2001	(21 posts)	Estado De ACPI
4.	16 Apr 2001 - 21 Apr 2001	(19 posts)	Se Ve Bien CML2
5.	18 Apr 2001 - 20 Apr 2001	(14 posts)	Nuevo Proyecto De Servidor X De Código Abierto
6.	18 Apr 2001 - 19 Apr 2001	(11 posts)	Rendimiento Del Borrado De Ficheros De Ext2
7.	20 Apr 2001 - 21 Apr 2001	(18 posts)	Estado De Soporte De Escritura En NTFS
8.	23 Apr 2001	(3 posts)	Detalles De NWFS En 2.4.3
9.	25 Apr 2001	(2 posts)	Página De Soporte De Vendedores A ECN

Tráfico del Núcleo #116 For 30 Apr 2001

By Zack Brown

Translated By: Cristian Othón Martínez Vera