|
Kernel Traffic Latest | Archives | People | Topics |
Wine Latest | Archives | People | Topics |
GNUe Latest | Archives | People | Topics |
| Czech |
| Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic |
FAQ de linux-kernel | suscribirse a linux-kernel | Archivos de linux-kernel | kernelnotes.org | Navegador de Código del Núcleo LxR | Todos los Núcleos | Núcleos Transportados | Documentos del Núcleo | Enciclopedia de Gary: Núcleo Linux | #kernelnewbies
Table Of Contents
Mailing List Stats For This Week
We looked at 1074 posts in 4476K.
There were 369 different contributors. 162 posted more than once. 0 posted last week too.
The top posters of the week were:
1. Problemas De Enrutamiento de IRQ En Las Series De Desarrollador
5 Dec 2000 - 18 Dec 2000 (15 posts) Archive Link: "PCI irq routing.."
People: Linus Torvalds
Linus Torvalds reportó:
Ok, ahora tengo dos confirmaciones independientes de gente (Adam Richter y Kai Germaschewski) quienes tienen hardware totalmente diferente, pero tienen el mismo problema: el enrutamiento de irq parece no funcionar para ellos.
En ambos casos es porque el espacio de configuración del dispositivo PCI ya tiene una entrada para la interrupción, pero aparentemente la interrupción no está actualmente enrutada al enrutador de irq.
No es claro PORQUÉ sucede esto, pero podrían ser varias razones:
El problema puede ser arreglado de forma relativamente fácil con solamente eliminar la prueba por cada "pci->dev" que ya haya sido establecido. Esto, dicho sea de paso, es importante también por otra razón - no hay nada que diga que un evento dormido no pueda desactivar el enrutamiento de irq, entonces _tenemos_ que tener alguna forma de forzar el enrutamiento de interrupciones para que tenga efecto aún si pensamos que ya tenemos el irq correcto.
De cualquier forma, Martin ciertamiente está también en lo correcto al reclamar que podrían haber bugs en el "otro" camino, y que sólo descartar completamente el irq que ya hemos reclamado tener podría ser malo.
Este es mi parche sugerido actual para el problema.
Adam, Kai, ¿podrían verificar que esto compone los asuntos en sus sistemas?
Alguien más que haya tenido problemas con enrutamiento de interrupciones PCI (tienden a ser dispositivos "nuevos" como CardBus, ACPI, USB, etc), puede verificar que esto compone las cosas o que por lo menos no descompone una configuración que haya empezado a trabajar con anterioridad...
Martin, ¿que piensas? Definitivamente necesitamos algo así, pero ¿tal vez podríamos agregar algunas pruebas de sanidad más?
Kai Germaschewski reportó éxito con el parche, pero Martin Diehl reportó que no había cambio en la conducta. Después de algunos vaivenes técnicos con Martin, Linus remarcó, "Ok, definitivamente necesita algo más de trabajo. Gracias por probar - No tengo hardware donde esto sea necesario." Después de algo más de discusión, Linus propuso una solución simple sin delicadeza después de obtener acceso a una máquina afectada. Pidio más comentarios, pero el hilo de la discusión terminó sin una solución definitiva.
2. 2.2 Vs. 2.4
7 Dec 2000 - 8 Dec 2000 (23 posts) Archive Link: "Linux 2.2.18pre25"
People: Alan Cox, Linus Torvalds
Este hilo de discusión contó con un bonito intercambio entre Linus Torvalds y Alan Cox. En cierto punto Alan mencionó, "He estado tratando de evitar composturas de VM para 2.2.18 para detener que las cosas se embrollen juntas y sean difíciles de depurar. El correr con envejecimiento de páginas me convence de que en 2.2.19 necesitamos ordenar algunos de los asuntos de vm urgentemente," -- y agregó con un guiño -- "y hacerlo más rápido que 2.4test." Y Linus replicó:
Ahh.. ¡El reto está hecho!
Tu y yo. Mano a mano. [original en español]
3. Argumentación Sobre La Calidad De Red Hat 7.0
7 Dec 2000 - 17 Dec 2000 (78 posts) Archive Link: "Signal 11"
People: Linus Torvalds, Jakub Jelinek, Alan Cox, Bernhard Rosenkraenzer, Miquel van Smoorenburg, Michael Peddemors, Theodore Y. Ts'o, Zack Brown, Alex Kanavin, Matt Wilson, John Summerfield, Chris Abbey, Stanislav Meduna, Mike A. Harris
Este es el ahora famoso hilo de discusión en el cual Linus Torvalds dijo:
Dicho framcamente, cualquier que use RedHat 7.0 y su compilador descompuesto para _cualquier cosa_ va a tener problemas.
No se porqué RH decidió hacer su versión idiota de gcc-2.96 (con certeza no fue aprovado por ninguna gente técnica de gcc - la gente de gcc también estaban molestas al respecto), y encuentro aún más sorprendente que ellos aparentemente SABÍAN que el compilador que estaban usando estaba completamente descompuesto. Incluyeron otro compilador (sin descomponer), y lo llamaron "kgcc".
"kgcc" es por "kernel gcc", aparentemente porque (a) se dieron cuenta que un núcleo erróneamente compilado es aún peor que compilar erróneamente alguna aplicación de usuario al azar y (b) gcc-2.96 está tan descompuesto que requiere bibliotecas especiales para el manejo de vtable chunks de C++ que es diferente, así que el gcc _funcional_ solamente puede ser usado con programas que no requieran tal biblioteca de soporte. Entre ellos el núcleo.
En caso de que no fuera obvio aún, considereo que RedHat-7.0 es básicamente inutilizable como plataforma de desarrollo, y espero que RH retroceda su compilador a algo que funcione mejor [realmente rápido ahora]. Aparentemente tiene problemas compilando cosas como las muestras CVS de X etc también (y obviamente, cualquier cosa que compile bajo gcc-2.96 es propenso a no funcionar en ningún lado más excepto con las bibliotecas descompuestas).
Jakub Jelinek replicó que los bugs reportados contra el gcc de Red Hat ya habían sido compuestos, a lo cual Linus replicó, "Eso es bueno. Es mejor aún si no juegas tanto a rápido-y-pierde con tu compilador a entregar." Jakub también respondió al punto de Linus acerca de que el gcc de Linux requiere bibliotecas especiales; él dijo, "Cualquier versión liberada mayor de g++ tiene libstdc++ incompatibles, aún g++ 2.95.2 si es compilado inicialmente bajo glibc 2.1.x es binariamente incompatible con g++ 2.95.2 compilado inicialmente bajo glibc 2.2.x (libstdc++ usa diferentes soname entonces; aún si usamos g++ 2.95.2 no tendríamos C++ binariamente compatible con otras distribuciones)." Linus replicó:
Si.
Y me doy cuenta que alguien dentro de RedHat realmente quiso usar una muestra para lograr que algún código en C++ compilara bien.
Pero al mismo tiempo arrojó la estabilidad de C por la ventana, usando una muestra no muy ampliamente probada para una nueva versión liberada mayor.
¿Estás diciendo seriamente que piensas que fue un buen intercambio? ¿O estás tan avergonzado de admitir que RH hizo algo estúpido?
En otro lugar, Alan Cox también replicó al mensaje inicial de Linus. Respondiendo a la afirmación de Linus de que el gcc de Red Hat no había sido aprobado por la gente técnica de gcc, Alan afirmó que todos excepto dos de los parches de Red Hat habían sido aceptados en el código fuente principal, lo cual él sintió que mostró su aprobación de la elección de Red Hat. Añadió, "El nombre molestó a la gente y fue desafortunado, pero se habló con la gente del compilador en Red Hat con las mejores intenciones detrás. Si lo hubiéramos llamado 'Red Hat cc' pienso que la gente hubiera estado mucho más ofendida de la forma en que hubieran sido desacreditados." Sobre el punto de Linus de que el gcc de Red Hat estaba tan descompuesto que requería bibliotecas especiales, Alan dijo, "Incorrecto - el cambio de formato de vtable de C+++ es parte de la progresión entendida del compilador y necesaria para alcanzar el cumplimento de estándares. gcc 295 también cambió los formatos internos. Desafortunadamente ninguno de los formatos de gcc295 y 296 son el formato final probablemente. Las gentes del compilador no estás dispuestas a garantizar nada hasta gcc 3.0, el cual tal vez salta para cuando 2.4 sea estable." Linus replicó:
Si preguntas a cualquier gente de gcc, la razón principal por lo que ellos piensan que fue una cosa realmente estúpida para hacer fue exactament que la 2.96 es incompatible con AMBAS versiones liberadas 2.95.x _y_ la 3.0 por salir.
Nadie le preguntó a la gente que sabía esto, aparentemente.
Alan señaló que gcc 2.95 tiene un formato diferente, gcc 2.96 tiene un formato diferente y egcs 1.1.2 tiene un formato difernte. Así, dijo, todos tienen formatos diferentes con respecto a todos, excepto que gcc 2.96 también era un compilador de c++. Bernhard Rosenkraenzer también replicó a Linus, diciendo en líneas similares como Alan, "La misma cosa es verdad de *cualquier* versión liberada de gcc. Por ejemplo, viendo el ABI de C++, 2.95.x es incompatible con AMBAS versiones liberadas egcs 1.1.x _y_ la 3.0 por salir." pero Miquel van Smoorenburg puso:
Sí, pero 2.96 es también binariamente incompatible con todas las distribuciones que no son redhat. Y como redhat es _la_ distribución que las entidades comerciales usan para liberar software, este fue un mal movimiento muy discutible.
Simplemente no hay excusa. Es demasiado obvio.
Alan acusó:
Excepto que convenientemente ignoras algunos cuantos hechos
Miquel replicó que había estado medio bromeando y que debía haber incluído una sonrisa. Pero Michael Peddemors preguntó, con respecto al segundo ítem de Alan, "Curioso ¿¿CóMO les dices a los vendedores??" A lo cual Alan replicó, "Cuando preguntan." Continuó, "Más util Dan Quinlann y la mayoría de los vendedores ponen juntos un conjunto recomendado de cosas para construir con y usa. Advierte sobre las trampas de las bibliotecas, cambios en el núcleo y qué empaquetamiento cuenta con soporte. Está lejos de ser perfecto y nada como las metas de L[inux] S[oftware] B[ase] pero es un inicio y al seguirlo proporciona aplicaciones que con un poco de cuidado corren en cualquier lugar." En este punto Theodore Y. Ts'o llegó con:
Con el interés de asegurarme que todos entienden la historia:
La Especificación de la Plataforma de Desarrollo Linux (LDPS) [por sus siglas en inglés] fue iniciado como resultado de una reunión informal vespertina después de una junta de LSB en Junio --- a la cual por cierto Red Hat no envió a ningún representante --- la discusión en el restaurante inició bajo las líneas de "Oh, por *DIOS* RedHat está a punto de hacer algo estúpido --- están liberando Red Hat 7.0 con muestras/beta de casi cualquier componente crítico del sistema excepto el núcleo --- y los vendedores que caigan en la trampa desarrollando contra Red Hat 7.0 no trabajarán con ninguna otra distribución. Esto va a ser *malo* para Linux."
Entonces sí, la razón por la que LDPS fue formada es para recomendar a los vendedores qúe deben construir y usar --- pero mientras Alan hace comentarios acerca de LDPS una vez que fue anunciado que un grupo de gentes estaba trabajando en la LDPS, no hay forma de que la LDPS pueda siquiera vagamente ser considerada una iniciativa Red Hat. (La LDPS es un grupo de trabajo separado que es parte de la FSG, así que es un grupo hermano al esfuerzo de LSB.)
Añadió, "Desde que Jim Kingdon dejó Red Hat (él estuvo en VA Linux por un rato, y ahora está en SGI), hasta donde yo sé nadie en RedHat está activamente participando en las actividades de LSB --- no han enviado a nadie a las juntas físicas de LSB, o participado en las conferencias telefónicas bi-semanales, o tomado ítems de trabajo para ayudar a terminar LSB. Alan participa en las listas de correo, y hace bastantes comentarios de gran ayuda, pero hasta donde yo sé ese es el límite de la participación de Red Hat tanto al trabajo de LSB o a la especificación LDPS. Hablando como alguien que ha estado contribuyendo tiempo y esfuerzo a LSB, sería grandioso si Red Hat llegara a estar más envuelto completamente en el LSB; yo (y estoy seguro de los demás voluntarios de LSB) daríamos la bienvenida a un nivel de participacion mayor de Red Hat."
No hubo respuesta.
Otro hilo de discusión menor se desprendió de la respuesta inicial de Alan al primer mensaj de Linus. A la esperanza de Linus de que Red Hat retrocediera su gcc tan pronto como fuera posible, Alan dijo:
¿ Como qué - gcc 2.5.8 ? El problema no es en general que las muestras tienen más bugs que antes, sino que los bugs están en lugares diferentes. Ambos egcs y gcc295 causaron problemas de compilación en X también.
Aún aconsejo a la gente: Usen egcs-1.1.2 para Linux 2.2.x. Pueden construir 2.2.18 con gcc 2.9.6 pero personalmente no estaría corriendo sistemas en producción con un núcleo construído en esa forma - pero NO por qeu gcc296 tenga más bugs sino porque los bugs van a estar en lugares diferentes y creo firmemente que la gente de sistemas en producción debe dejar a los locos encontrarlos ;)
Linus replicó:
gcc-2.95.2 por lo menos es una versión liberada real, de una rama que está mantenida activamente - así un 2.95.3 es problable que suceda razonablemente pronto, componiendo tantos problemas como sea posible _sin_ ser incompatible como lo son las muestras.
O tan solo quedarse en 2.91.66 (egcs).
[...]
He aplaudido a RedHat por hacer las muestras disponibles, pero deben ser marcadas como MUESTRAS, y no como el compilador principal sin forma de arreglar los malditos problemas que causa.
Como está, cualquiera que haga desarrollo está probablemente mejor en RH-6.2. Esto es doblemente verdadero si tienen la intención de liberar binarios.
Alan señaló que 2.96 estaba activamente mantenido -- por CygnusHat -- y que ellos alimentaban todos los cambios al equipo núcleo de gcc. Sobre marcar las muestras como muestras, Alan dijo, "Eso fue confuso y que sea confundido por alguien como una versión liberada oficial del grupo GNU es algo que nunca tuvimos intención y de lo cual ya nos hemos disculpado. Fue hecho sin malicia o mal intencionado." Y sobre la recomendación de Linus de que los desarrolladores usen Red Hat 6.2 en lugar de 7.0, Alan estuvo de acuerdo, diciendo, "Recomendamos enfáticamente que la gente use 6.2 para desarrollar binarios para versiones liberadas en general a menos que tengan requerimientos específicos para glibc 2.2. Estos son los mismos lineamientos que la documentación LSB 'ups aún no hemos terminado aquí hay un rapidín por ahora' recomienda."
Bernhard también replicó a la sugerencia de Linus de 2.95.2 como siendo mantenido activamente. Bernhard afirmó que no estaba mantenido activamente como lo podría estar, y agregó que una comparación de número de parches en el árbol 2.95 contra el árbol 2.96 en la distribución Rawhide de Red Hat mostrarían más actividad en 2.96. Añadió que no pensaba que el código 2.96 actual tuviera más bugs que el código 2.95 actual. Llegó a afirmar que la sugerencia de Linus de egcs "podría ser buena para el núcleo, pero no es aceptable para C++." Con respecto a la comparación de Bernhard de 2.95 principal contra 2.96 en Rawhide, Linux replicó:
Echa una mirada a las diferencias en linux-2.2.x y linux-2.3.x.
linux-2.3.x era endemoniadamente más "activamente mantenido".
Pero nadie realmente considera que esto sea un argumento para RedHat (o para alguien más) para instalar núcleos 2.3.x por omisión. Seguro, muchas distribuciones tiene un "núcleo para hacker", pero NO está instalado por omisión, y está claramente marcado como experimental.
Tus argumentos no tienen sentido.
El compilador es generalmente _más_ importante para la estabilidad del sistema que el núcleo. Una "versión liberada real" implica que por lo menos tuvo prueba, y que la gente sabe cuáles tienden a ser los puntos de problemas.
Nota que el "saber cuáles tienden a ser los puntos de problemas" es importante.
Para cualquiera que esté interesado, hubo alguna mención sobre la inestabilidad de 2.96 en BROKEN KCREF. 2.96 aún no era recomendado por BROKEN KCREF (aunque Alan sintió que el problema era más con el núcleo que con el compilador). Horst von Brand coincidió con esta afirmación en BROKEN KCREF, aunque Red Hat ya estaba recibiendo bombardeos por presentar su muestra de gcc bajo el nombre falso 2.96; y Peter Samuelson sintió que 2.96 descompondría cualquier núcleo conocido, en BROKEN KCREF.
(ed. [Zack Brown]Personalmente, pienso que Red Hat no es lo suficientemente vocal sobre impulsar a la gente a participar en el desarrollo de su distribución. Han contratado a algunas gentes verdaderamente sorprendentes para trabajar en eso pero la distribución Red Hat aún parece sufrir de una naturaleza más cerrada que algo como Debian, o el mismo núcleo.
La única lista pública de correo electrónico para desarrolladores adecuada para el desarrollo actual de Red Hat, por ejemplo, tiende a estar con relativamente bajo tráfico y fuera de tema. Conté 133 mensajes para casi todo el mes de Diciembre, o 4 a 5 mensajes por día en promedio. Durante el mismo periodo, debian-devel recibió cerca de 2600 mensaje, o más de 85 por día; mientras linux-kernel recibió más de 4300, o más de 140 por día -- más por día que el tráfico de la lista de Red Hat durante todo el mes. Y del tráfico de la lista de Red Hat, la vasta mayoría fueron preguntas de usuarios. Solamente tres remitentes tenían direcciones de email redhat.com, y sus contribuciones totalizaron 16 mensajes. Ningún esfuerzo fue hecho para hacer saber a las otras gentes que sus mensajes fueron fuera de tema, o para explicar cual era el verdadero tema actual de la lista. La única razón que encontré fue porque yo pregunté en la lista en Octubre pasado.
Dije, "He estado buscando una lista de correo de desarrollo de Red Hat, como debian-devel, donde la distribución es actualmente creada y mejorada. Parece que redhat-devel-list es para gente haciendo desarrollo de otros proyectos, en un sistema red-hat funcionando. ¿Estoy algo perdido?" Alex Kanavin replicó, "Bueno, creo que nadie está completamente seguro para qué es esta lista, pero ciertamente puedes discutir este tipo de cosas aquí. Y no olvides que la mayor parte del desarrollo actual toma lugar en el bugzilla de RH y hay algo de eso en http://www.labs.redhat.com." Él también dió un apuntador a la Red de Desarrolladores de Red Hat, pero Matt Wilson (de Red Hat) replicó, "Si quieres que un desarrollador en Red Hat lea algo, los foros web no son el lugar para visitar por el momento. Es justo aquí." Matt también replicó a mi mensaje original, diciendo, "estás en el lugar correcto. Había solo un poco de discusión OT..."
Hubo varias respuestas a esto. John Summerfield dijo, "la última vez que ví la descripción de la lista (admitidamente hace un tiemp) la definición de "desarrollo" era lo suficientemente amplia para incluir el desarrollo de programas. De hecho, esa es la razón por la que originalmente me suscribí." Y Chris Abbey añadió, "hasta el momento esta es la primera vez que he visto que algún @redhat.com responde esta pregunta. Se que cuando por primera vez ví esta lista pregunté la misma pregunta y nunca obtuve una respuesta... Lo he visto algunas cuantas veces más en los últimos tres años. Me da gusto ver esa afirmación de Matt. Se que significa que algunas de mis preguntas saldrán de esta lista, pero también me da más confianza de que algunas otras (como el guión de construcción para el árbol de instalación de nfs en el que estoy trabajando) serán dirigidos a algún lugar que las gentes @redhat.com verán."
Stanislav Meduna también replicó a Matt, diciendo, "Bien, hasta donde yo recuerdo, aún tengo que ver alguna discusión real acerca de crear y mejorar la distribución en esta lista."
Mike A. Harris también replicó a Matt, diciendo, "Más como un _MUCHO_ de discusión OT. ;o) Parece como que muchas gentes se inscribieron aquí pensando que esta es la lista "pregunta todas las preguntas para cada versión liberada" de Red Hat (redhat-list). Los mensajes temáticos contra los fuera de tema son 1:10 respectivamente. ;o" Chris estaba esperanzado a que eso cambiaría, ahora que las gentes sabían mejor para qué se suponía que era la lista. Hubo algo de discusión sobre formas de mantener la lista en el tema, y el hilo de la discusión se acabó.
Aparentemente, no mucho ha cambiado desde Octubre. Creo que hay varios factores contribuyendo a esto. Primero, es bastante difícil aún encontrar esta lista (me tomó un rato), y después saber qué hacer en ella una vez que fue encontrada. Como yo lo ví, muchos de los suscripotes de la lista no sabían que estaban en la una y única lista pública de desarrolladores de la distribución Red Hat.
Segundo, aún los desarrolladores Red Hat no publican mucho en la forma de ideas acerca de la dirección del proyecto, posibles características o nuevos paquetes, nuevos parches, etc.; responden a reportes de bugs cuando alguno sale, pero al respecto de cualquier otro desarrollo real de la distribución Red Hat, la lista está vacía.
Y tercero -- o tal vez tan sólo un sumario del problema entero como yo lo veo -- parece que no hay un liderazgo real, del tipo que el bazaar requiere para prosperar. Nadie es estimulado en trabajar desarrollando Red Hat. Nadie tiene una pista de qué tipo de trabajo sería aceptado en la distribución, y qué tipo de trabajo no sería requerido. Simplemente hay una entidad nebulosa llamada "Rawhide", y otra entidad nebulosa llamada "Los Desarrolladores". ¿Quiénes son estos desarrolladores? La lista de de suscriptores a la lista de correo es privada. Los mismos desarrolladores, con algunas excepciones, nunca se escucha de ellos. La lista de correo se arrastra sin dirección. Y un día, Red Hat 8.0 sale.
Algunas gentes podrán ver una duda aquí en Red Hat corp., y acusarlos de tratar de sofocar la lista de desarrolladores, para que toda la discusión de desarrollo tome lugar enteramente dentro de casa, fuera de los ojos ávidos de sus competidores. Ese temor debe ser la causa de algo de la amargura contra Red Hat encontrada de vez en cuando en linux-kernel y otros lados. No sé cual es la verdad, pero su lista actual de desarrollo está lejos de ser un pilar de fortaleza para la comunidad de software libre.
)4. kapmd Atascando El CPU: La Saga Continúa
11 Dec 2000 - 22 Dec 2000 (18 posts) Archive Link: "kapm-idled : is this a bug?"
People: Rik van Riel, Nick Holloway, Kurt Garloff
Alguien notó que el proceso kapm-idled normalmente toma entre 60% y 80% del CPU, pero sólo cuando no hay otros procesos corriendo. Rik van Riel replicó, "¿Qué supones que representa el 'idled' [inactivo] en 'kapm-idled'?" Nick Holloway replicó, "Sabemos que fue un intento para evitar que la gente se quejara acerca del hecho de que "kapm" estaba saturando el CPU. Parece que no funciona." El remitente original también replicó a Rik, diciendo que la conducta era engañosa y parecía mostrar un CPU constantemente cargado. Y Kurt Garloff puntualizó, "Aún pero: Anteriormente podías sacar conclusiones de la parte sys de tu carga. Eso ya no es posible. Me disgusta a mí también y lo considero un bug cosmético. (Que es mucho mejor que un bug real, no lo tomen a mal. Si componer el bug cosmético introduce uno real: ¡No lo hagan!)" Hubo alguna discusión de posibles mejoras a la situación, pero nada concluyente emergió de la lista. Para una discusión anterior en este tema, vea BROKEN KCREF.
5. Dificultades Al Obtener Documentación De ServerWorks
16 Dec 2000 - 19 Dec 2000 (8 posts) Archive Link: "ServerWorks docs?"
People: Rico Tudor, Dave Jones, Dan Hollis, Jeff Nguyen, Matthew Jacob, Jim Forster
Rico Tudor preguntó, "¿Alguien tiene material de referencia para el northbridge de ServerWorks? Quiero agregar su juego de chips a mi utilería de monitoreo de ECC, pero su sitio web es un poco más que dirigido a mercadotecnia. Además, no responden a e-mail" J . A . Magallon dío un vínculo a algunos controladores ServerWorks. Pero Dave Jones sintió que esta página solo indicaba que "las oportunidades de que ellos públicamente liberaran información al nivel de registros parecían muy pequeñas." Añadió que él había tratado varias veces de obtener documentos de ellos y había fallado. Dan Hollis remarcó, "serverworks requiere que no solamente se firme un NDA, también que todo el desarrollo sea en sitio en sus cuarteles generales en santa clara bajo su supervisión directa." Pero Jeff Nguyen dijo, "Serverworks quiere dar soporte a la comunidad Linux. Por eso están dispuestos a compartir cierta información a desarrolladores sin arriesgar la Propiedad Intelectual. ASL ha estado trabajando recientemente con Serverworks para dar soporte al proyecto lm-sensor y otro desarrollador de software Linux. Hazme saber si necesitas alguna ayuda con la información del juego de chips." Rico replicó que sin los documentos, el problema básico continuaba. Prosiguió:
Mi interés en la documentación de ServerWorks tiene dos partes: primera, para expandir el soporte de juegos de chips en mi utilería ECC y segundo, para dar mejor soporte a las máquinas basadas en ServerWorks en mi lugar de trabajo.
En nombre de la comunidad Linux, firmaría un NDA si fuera civilizado y si mi código permaneciera, obviamente, del dominio público. Podría visitar ServerWorks en mi siguiente incursión al Área de la Bahia.
Más importante para mí es el acceso legible a la documentación técnica para dar soporte a las máquinas en el trabajo. Vengo de la era cuando las PDP-11 eran entregadas con diagramas de circuitos, el SO, y el código fuente para el SO. Las cosas han ido cuesta abajo desde entonces. No voy a tomar el siguiente avión al Área de la Bahía para revisión "de vista" de un documento cada vez que surja un problema. En este sentido, compañías como IBM Storage e Intel ganan mis felicitaciones, y mis dólares. ServerWorks pueden obtener algunos de esos dólares porque tiene un juego de chips accesible que soporta 4 GB, pero esa ventaja puede cambiar de la noche a la mañana. Es sólo que la Propiedad Intelectual tiene una larga media vida estos días, a menos que puedas arrinconar el negocio de la construcción de pirámides.
Estas compañías deben evaluar su postura propietaria en relación a las ventas perdidas, más mientras el código libre se acelera. ATI, Matrox, Adaptec: ¿necesitamos decir más¿ Pero entonces, estoy predicando al coro. Tal vez ServerWorks debe ver en sus corazones, y decidir que pequeña parte de su Propiedad Intelectual tiene valor enorme, eterno -- el tipo que los mantendrá nadando en abundancia, como el Tío Rico. El resto de la especificación, como la miserable circuitería ECC que han hecho un millón de veces antes, ¡libérenlo ya! Sus adoradores fanáticos de Linux están esperando.
Matthew Jacob tuvo algunos puntos de hechos que hacer contra el mensaje de Rico. Primero, señaló, "El único código fuente para el SO que llegó 'gratis' que yo recuerde para el PDP-11 fue RSX-11- pero era sólo el núcleo desnudo. El código del sistema de ficheros y de las utilidades no estaba disponible. En ese tiempo, como probablemente puedes bien recordar, la licencia del código de UNIX de WECO era de 40K$ para v7 en Sidereal." Acerca de las felicitaciones para IBM e Intel, continuó, "No aplaudan a Intel ni IBM muy fuerte. En particular, Intel. Tan solo *traten* y obtengan documentación de ellos acerca de su grandioso chip gigabit ethernet."
Jeff también replicó a Rico, citando un email de Jim Forster de Serverworks, en el cual Jim dijo, "Queremos dar acceso a la comunidad Linux tan rápido como sea posible; coincidimos con usted de que tiene sentido de negocios hacerlo. Dado el hecho de que nuestra Propiedad Intelectual es nuestro único producto, no podemos liberar nuestros documentos técnicos al mundo por completo. Hemos estado trabajando para crear un extracto de nuestros documentos para dar acceso a la comunidad Linux. Como una compañía pequeña experimentando un tremendo crecimiento, nuestra infraestructura de soporte debe enfocarse en nuestros clientes existentes. En este momento, no tengo una fecha estimada de liberación para el extracto técnico. ... Estamos continuando nuestro trabajo para dar acceso a la comunidad Linux. ¿Puede pensar en algunos métodos alternativos para dar acceso a la comunidad Linux sin exponernos nosotros mismos? Realmente estoy abierto a nuevas ideas..."
Jeff explicó:
Jim respondió a mi Email acerca de soporte para lm-sensor. Concedido que Serverworks no ha liberado ninguna información al público. Pero están planeando extraer cierta información de los juegos de chips que podría ser útil para tí. También están abiertos a idea[s] de la comunidad Linux.
Después de que Jim replicó, Phil Edelbock del grupo lm-sensor salió con una buena idea. Ells decidieron preguntar a Jim por un conjunto específico de información correspondiente al proyecto. Así que en lugar de ir por toda la documentación, ellos sólo pidieron un pequeño subconjunto. La idea funcionó porque Serverworks pudo proporcionar la información rápidamente.
Esto podría ser una buena aproximación para obtener información de Serverworks fuera de una NDA.
No hubo respuesta.
6. Problemas De Dependencia De Orden De Enlace
16 Dec 2000 - 17 Dec 2000 (13 posts) Archive Link: "[PATCH] link time error in drivers/mtd (240t13p2)"
People: Keith Owens, David Woodhouse, Alan Cox
Rasmus Andersen publicó un pequeño parche para borrar la declaración 'static' de cfi_probe struct, que causaba que no fuera compartido. Sacando esto permitía que el núcleo pasara exitosamente el proceso de enlace, aunque Rasmus admitió que no estaba seguro si la conducta que él había cambiado había de hecho sido intencional o no. Keith Owens replicó que entre test11 y test12, alguen había agregado código para hacer compilación condicional; lo cual, dijo Keith, agregó complejidad innecesaria y estaba por lo tanto mal. Afirmó que este cambio anterior debía ser deshecho y cfi_probe regresar a set una declaración estática. De cualquier forma, David Woodhouse defendió el cambio, señalando que la complejidad condicional era necesaria para acomodar variaciones en el orden de enlace. A esto, Keith replicó, "Lidiando con compilación condicional porque el orden de enlace es incorrecto es la compostura equivocada. El mtd/Makefile debe enlazar los objetos en el orden correcto." Él listó lo que el sintió que debía ser el orden apropiado de enlace de varios ficheros .o, y sugirió un cambio de orden de enlace para mtd.h; pero David aún no estuvo de acuerdo con esa solución. Él dijo:
La compilación condicional es mucho más obvia para la gente que asuntos sutiles con el orden de enlace. Entonces yo prefiero evitar lo último a toda costa.
Tengo que tener alguno de compilación condicional en mi árbol para permitir que compile bajo 2.0 uClinux. Reconozco que no tiene que entrar en 2.4, pero obviamente prefiero que el código en 2.4 sea tan cercano a mi copia funcional como sea posible.
Picaré en él y trataré de salir con una solución más limpia. Puede ser que pueda cambiar todas las cosas condicionales dentro de compatmac.h y dejar la ruta de código 'real' en un estado más limpio que el actual.
Keith preguntó, "El resto del núcleo ya depende totalmente de esos asuntos "sutiles" con el orden de enlace. ¿Por qué mtd debe ser diferente?" Alan Cox alertó, "¿Por qué mtd debe estar descompuesto sólo porque el resto de los Makefiles lo está?" David también replicó a la pregunta de Keith, diciendo, "Porque yo mantengo el código de MTD y quiero que así sea. Pienso que las dependencias de orden de enlace son feas, innecesarias y con más tendencia a ser problemáticas que las alternativas. Codificaré una alternativa que sea más limpia que el código actual, y Linus puede aceptarla o no, como vea si queda." Keith señaló, "Tu elección. Tan solo toma en cuenta que si CONFIG_MODULES=y pero los objetos mtd son construídos dentro del núcleo entonces mtd _debe_ tener un orden de enlace correcto. Considera una configuración con CONFIG_MODULES=y pero cada opción mtd establecida a 'y', el orden de enlace es crítico. En el momento que tienes dos o más módulos mtd construídos en el núcleo entonces estás atorado con asuntos de orden de enlace, no importa lo que hagas. Por supuesto puedes inventar y mantener tu propio método único para controlar el orden de inicio de mtd ..." David admitió que no tenía respuesta para este problema, y mencionó "El parche fue puesto ahí por alguien para arreglar la compilación en 2.0 - y noté que hacía que el problema de orden de enlace se fuera para ciertas configuraciones." Continuó, "Trataré de encontrar una forma limpia de hacer que el código de MTD trabaje en todas las configuraciones sin tener que hacer eso. Si realmente llega a hacer lo anterior, probablemente tan sólo me rendiré y lo dejaré 'descompuesto' (en mi opinión) junto con el resto del código del núcleo que como tú dijiste ya tiene dependencias de orden de enlace." Fin de la Discusión (mr).
7. Beneficios De NFSv3
17 Dec 2000 - 18 Dec 2000 (5 posts) Archive Link: "mount and 2.2.18"
People: Alan Cox, Andrea Arcangeli
En el transcurso de la discusión, Brady Montz preguntó si alguien sabía de algunos documentos que explicaran los beneficios de NFSv3. Alan Cox replicó, "No a la mano pero puedo dar un muy breve sumario del más grande - velocidad de escritura. NFSv2 hace escrituras síncronas con una mínima cantidad de escritura por adelantado. NFSv2 recolecta las escrituras en el servidor y las calendariza como el servidor lo desee. El cliente manda peticiones de escritura pero antes de que las pueda asumir completadas y por lo tanto limpia esa parte de su caché que tiene que consolidarlas. Normalmente la consolidación está bien hecha después de que la E/S alcanza los discos del servidor, si no espera" y Andrea Arcangeli agregó, "otra característica relevante es que con 2.4.x y 2.2.18aa2 también puedes obtener ficheros de >2G con NFSv3 (como sobre ext2)."
8. Depurando Sistemas Que Usan Módulos Binarios
18 Dec 2000 (4 posts) Archive Link: "booting without VGA"
People: Abraham vd Merwe, Alan Cox
Abraham vd Merwe tenía Linux corriendo en su cámara, usando el controlador sólo-binario DiskOnChip de M-Systems para almacenamiento y como un dispositivo de arranque. Pero él reportó, "El problema es que si arranco con un núcleo CON el soporte a vga habilitado, arranca bien. Si desactivo el soporte a vga no parece arrancar. Lo que lo hace aún más extraño es que si arrancamos con el mismo núcleo sin vge usando un disco IDE como dispositivo de arranque también arranca bien. " Alan Cox replicó, "Por favor pide a M-Systems que depuren tu problema. Nosotros no tenemos el código fuente para su controlador así que no podemos ayudarte."
9. Asuntos De Rendimiento De VM Con Respecto A Reservación De Memoria
18 Dec 2000 (4 posts) Archive Link: "VM performance problem"
People: Richard B. Johnson, David S. Miller
Richard B. Johnson notó lo que se veía como un problema de rendimiento en el subsistema de Memoria Virtual de los núcleos 2.2.17, 2.4.0-test9, y 2.4.0-test12. Él había escrito un programa de prueba para reservar (vía malloc()), usar, y despues liberar algo de RAM. Notó que toda la memora era liberada rápida y eficientemente si el terminaba el programa con CTRL-C, mientras si al programa se le permitía alcanzar su propio código de retiro de reservación, "tomaría más de 1 minuto entero!! En este momento, hay una enorme cantidad de actividad de fichero-de-intercambio desarrollándose." Argumentó, "Como muchos programas reservan/desalojan datos estableciendo la dirección de interrupción via malloc(), esto representa un castigo severo al rendimiento. ¡Desalojar páginas no debe resultar en ninguna actividad del fichero de intercambio! ¡Esta actividad debe ocurrir solament cuando sea enviado al fichero de intercambio, necesite regresar de dicho archivo y nada necesite ser regresado durante un desalojo! Como las páginas de usuario no son reordenadas (o no deben serlo), no debería haber actividad de intercambio durante el desalojo de páginas." David S. Miller preguntó, "¿Exactamente cómo son reservados/desalojados esos espacios temporales de memoria? ¿Estás absolutamente seguro de que el proceso de retiro de reservaciones no hacer cargas de o guarda en los espacios temporales como lo haría una implementación de free(3)? Eso causaría que las páginas fueran succionadas de regreso del espacio de intercambio." Richard replicó que sólo había usado free(), como cualquier programa típico de usuario lo haría. Pero David replicó, "malloc y free mantienen su piscina de espacios temporales de memoria libres usando listas ligadas, así un free() hace dos almacenamientos a los (2 * sizeof(void *)) bytes antes o después de ese espacio temporal. Por eso la actividad de intercambio. Usa mmap()/munmap() directamente y maneja las cosas tú mismo totalmente para deshacerte de esto."
10. Árbol 2.4 de Alan
18 Dec 2000 (8 posts) Archive Link: "Linux 2.4.0test13pre3ac1"
People: Alan Cox
Alan Cox inició recientemente el mantenimiento de su propio conjunto de parches contra el árbol 2.4-test, enviando algunos a Linus Torvalds para versiones liberadas oficiales de desarrolladores. Anunció 2.4.0test13pre3-ac1 y dijo, "Este es más para que la gente pueda ver qué he mezclado en mi árbol y qué ha salido de él. El parche para los aventureros está en ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4.0test/" y publicó el Changelog:
Alexander Viro señaló que para el ítem 2 (Compone fuga en llamada de sistema link ()), la compostura que salió originalmente no vino de él sino de Christopher Yeoh. Hubo muy pocas otras discusiones, pero Tim Waugh publicoó algunos parches.
11. Especificación ATA Disponible Con Licencia Clic-A-Través
18 Dec 2000 (3 posts) Archive Link: "SerialATA Release, sortof........"
People: Andre Hedrick, David Weinehall
Andre Hedrick anunció:
La especificación Serial ATA (500 páginas) está disponible ahora al público bajo ciertas condiciones "clic-para-aceptar". Hagan clic en el enlace "specification" al final de la página en http://www.serialata.org/. Esper que las condiciones sean aceptables. El fichero es MS Word dentro de un zip.
Esto es sólo para los que les importa... por favor no me pregunten por mi copia porque soy un miembro de este grupo de trabajo y estoy atado bajo la NDA.
David Weinehall replicó, "Bueno, pienso que la mayoría de la gente puede ser feliz con las condiciones. Ahora, el formato, ese es un tema completamente diferente. Con toda tu influencia, apuesto que ¡¿los podrías persuadir a por lo menos correr el documento a través de Acrobat Distiller para convertirlo en un .pdf?!" Andre replicó, "Mi mal por reenviar información desde dentro. Yo sabía que mis copias estaban en PDF, pero no sabía si ellos combinaron todas las erratas en un documento más nuevo o que...."
12. Alcanzando Mayor Compresión En Binarios Del Núcleo
20 Dec 2000 - 21 Dec 2000 (5 posts) Archive Link: "tighter compression for x86 kernels"
People: John Reiser
John Reiser anunció, "La versión liberada v1.11 del compresor de ejecutables UPX http://upx.tsx.org ofrece nueva y más estrecha re-compresión de núcleos Linux comprimidos para x86. Ahorros de espacio adicional de cerca del 15% han sido vistos usando "upx --best vmlinuz" (ejemplo: 617431 ==> 525099, ahorrando 92332 bytes). Tanto el código fuente (GPLv2) como el binario pre-compilado para x86 están disponibles." Adrian Bunk señaló que el proyecto no estaba completamente GPLeado, porque tenía una excepción especial para una parte de los binarios. Dió una liga al texto de la licencia, pero Frank v Waveren y John argumentaron que esto era meramente un caso de licencia dual, no de restricciones adicionales; y John explicó "El equipo UPX posee todo el copyright sobre todo lo de UPX y en cada parte de UPX. Por lo tanto, el equipo UPX puede escoger cuáles licencia(s), y ha escogido dos. Una de ellas es GPLv2. El equipo UPX entiende, e intenta cumplir completamente, sus obligaciones bajo GPLv2 cuando cualquier software que está sujeto a la GPLv2 es contribuído a UPX y redistribuído por el equipo UPX. La otra licencia está detallada en el fichero LICENSE, pero puede ser resumida como: libre de usar si no es modificado , y si es usado solamente para invocar el programa, y es sublicenciable sólo bajo los mismos términos. Esto permite usar UPX para empaquetar un ejecutable no-GPL. Los usuarios de UPX (como es distribuido por el equipo UPX) puede escoger ya sea usar UPX de acuerdo a la GPLv2, o de acuerdo a la otra licencia."
13. Protección Contra Copia Basada En Hardware
20 Dec 2000 - 22 Dec 2000 (3 posts) Archive Link: "CPRM copy protection for ATA drives"
People: Alan Cox, Andre Hedrick
Alguien dió un apuntador a un artículo en theregister, discutiendo protección contra copia basada en hardware. Dijo que la tecnología parecía fácil de vencer, pero Alan Cox replicó, "Es probablemente muy difícil de vencer. También en su forma actual significa que puedes sacar fuera las herramientas de defragmentación de disco. Muertas, idas. Bienvenidos al Estado de la Policía Unida de América." También agregó, "Estoy sólo esperando pur unas cuantas demandas legales de clase de acción contra los fabricantes de unidades cuando las herramientas de respaldo de la gente no puedan funcionar." A esto último, Andre Hedrick replicó:
este es uno de los asuntos que mostré junto con muchos otros durante la Junta Plenaria de Diciembre. Para los registros, pude intensificar el asunto con mis objecciones para posponer la adopción por 60 días. Este tema saldrá de nuevo en Febrero. Solamente puedo representar mi interés como un consultor en el Comité T13, porque no hay organización oficialmente conocida como "Linux".
¡Espero que se genere mucho calor alrededor de CPRM, pero todos aquí saben que se puede generar tanto que sea desechado! Si deseas enviar una nota para quejarte sobre el tema, llevaré tus puntos a la junta.
Fin del hilo de la discusión.
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0. |