Tráfico del Núcleo #124 For 2 Jul 2001

Notará que algunos de los artículos de este ejemplar fueron escritos por Adam Buchbinder, quien también colaborará conmigo en futuros ejemplares. Cualquiera que esté interesado en hacer lo mismo es bienvenido para contactarme. Escribir el Tráfico del Núcleo es un gran trabajo. Puedo requerir ayuda.

There were 445 different contributors. 210 posted more than once. 154 posted last week too.

Tim Hockin preguntó acerca de EEPRO/100 S bajo Linux, y Kelledin Tane replicó que los controladores de Intel daban soporte a la tarjeta bajo Linux, y que estaban bajo la licencia GPL. Pero J. S. Peatfield replicó:

El controlador e100 de intel clama dar soporte a estas tarjetas (el adaptador de escritorio 100 S, eso es), pero de hecho los controladores se bloquean bajo carga pesada de UDP (por lo menos eso me hace en 2.2.19). Parece que sólo es un problema con estas tarjetas nuevas, el e100 es sólido con tarjetas más viejas (y cosas como la 100VE que está en la tarjeta madre en muchos del Este).

Intel está trabajando en componer los bloqueos, ellos pensaron que estaba relacionado a la suma de comprobación de descarga aunque apagándola no previene los bloqueos. La versión 1.66 es mucho más estable que la 1.55a (la 1.55a se bloquea después de 60-80M de tráfico en esas tarjetas), estoy esperando la siguiente versión para ver si lo han arreglado.

El controlador no es GPL (no se porqué no lo es) y no tiene soporte para el asic de encriptación en tarjetas madre que lo tienen (e Intel no tiene deseos de liberar detalles de este asic para que otros puedan escribir controladores para usarlo).

Empezando hoy, Paul Mackerras (paulus@samba.org) está asumiendo el mantenimiento del árbol de Linux PPP 32-bit y continuará como el mantenedor del árbol de Linux/PPC 64-bit.

Los árboles estable y desarrollo (2.2 y 2.4) se moverán del repositorio ftp/rsync/BitKeeper de FSMLabs al árbol CVS de vger.kernel.org. Los cambios deberán continuar fluyendo al árbol principal disponible en kernel.org.

Paul continuó, "Cort ha puesto una enorme cantidad de tiempo y esfuerzo en mantener el transporte PowerPC de Linux durante los pasados 5 o 6 años, y por mi parte quiero reconocer públicamente y agradecerle por eso. No siempre ha sido una tarea fácil, lo se, porque hay una amplia variedad de opiniones dentro del campo PPC/Linux y Cort ha sido el hombre en el punto para lograr el balance entre los intereses en competencia. Y por mi parte extrañaré el tiempo, esfuerzo y recursos que él ha puesto en las cosas de infraestructura tales como el repositorio, las páginas web, el sitio ftp etc." La página inicial del transporte está en http://www.linuxppc.org.

Holger Kiehl y otros han estado utilizando el parche de Ben Greear para dar soporte a redes virtuales VLAN en el núcleo 2.4. dijo que no había tenido ningún problema con el parche por un largo tiempo, y preguntó porqué no había sido incluído en el árbol de Linus. Ben, el autor del parche, replicó:

He tenido una buena discusión con Dave Miller hoy, y hay un asunto sobresaliente para aclarar antes de que mi parche 802.1Q VLAN pueda ser considerado para aceptación en el núcleo:

¿Las VLANs deben ser dispositivos o alguna otra cosa?

Yo siento fuertemente que deben ser dispositivos por muchas razones.

Hace de la integración con herramientas del espacio de usuario (ip, ifconfig, arp...) algo trivial.
Es lógicamente correcto, una VLAN es un (net_)device y en todas formas actúa como uno.
No introduce ninguna degradación de rendimiento de ruta rápida del cual tenga conocimiento. La única ruta lenta involucra la búsqueda lineal de un dispositivo por nombre (o id??). Esto puede ser arreglado haciendo un hash de la lista, si es necesario.
Ambos parches VLAN han usado VLANs-como-dispositivos desde el inicio, y no he visto efectos malignos a este aproximación que puedan ser mitigados por alguna otra arquitectura.

De cualquier manera, necesitamos que toda la comunidad coincida más o menos que mis argumentos (y otros que los compartan) suenan bien. Así que por favor, traigan sus quejas al frente ahora...¡o parchen para siempre a mano!

También, otras quejas o sugerencias para el código VLAN deben ser mencionadas también, !por favor!

Si desean ver el parche, obtengan la versión 1.0.1 de mi página de vlan: http://scry.wanfear.com/~greear/vlan.html Hoy liberaré una nueva en poco tiempo con el código de búsqueda-rápida-de-dispositivo (que ya está #ifdefinido) completamente eliminado, por deseo de Dave.

Un montón de gente se alineó en apoyar el trato de VLANs como dispositivos, y Dax Kelson lo puso, "Conceptualmente, las VLANs como dispositivos de red es facilísimo." Pero David S. Miller replicó, "Las preocupaciones al nivel de implantación técnica necesitan ser consideradas así como las de "se ve bien"." Gleb Natapov argumentó, "¿Cómo puedo implementar la capa intermedia entre L3 y L2 en el núcleo actual? Eso es todo de lo que se trata VLAN. La única forma de hacerlo hoy es pretender ser un dispositivo de red para L3, hacer su trabajo (agregando el encabezado VLAN) y el trabajo de L2 (construir el encabezado ethernet) y encolar el paquete en el dispositivo maestro para la transición. Esto es lo que el módulo ipip hace, es lo que el módulo bonding hace y muchos otros. Y esto es porque L1 y L2 están acoplados estrechamente juntos en el núcleo ahora. De hecho es casi imposible implementar nuevos protocolos L2 sin cambiar la estructura net_device. Algo debe ser hecho acerca del diseño de L1+L2 hasta entonces pretender que sea net_device la única solución si quieren que VLAN sea transparente para protocolos L3. Si quieren implementar VLANs solamente para la capa IP esto puede ser hecho diferente por supuesto."

No hubo respuesta, pero Ben replicó que tratar las VLAN como un dispositivo ha sido "la forma más sencilla de implementar cosas. Me ha permitido no tener que tocar nada de la capa 3, y no he tenido que parchar ningún programa de espacio de usuario como ip o ifconfig." Agregó, "No estoy aún seguro si los que se niegan han tenido otra idea, a ellos solamente no les gusta tener muchas interfaces. Originalmente, había reclamos de ineficiencia, pero parece que aparte de cosas como 'ip' e ifconfig, no hay otros problemas serios de rendimiento de los cuales tenga conocimiento."

Alan Cox anunció 2.2.20-pre4 y agregó, "Linux 2.2 está ahora firmemente en estado de mantenimiento. Los partes para buenas nuevas ideas pertenecen a 2.4. Generalmente los nuevos controladores pertenecen a 2.4 (posiblemente en 2.2 también después de que 2.4 los muestren estables). Esperen que ahora yo sea muy puntilloso en cambios al código principal."

Zack Weinberg dijo, "El código de tubería anónima en 2.2 no revisa el valor regresado de copy_*_user. Esto puede conducir a pérdidas silenciosas de datos." 2.4 no tiene el bug, dijo, ya que el fichero relevante ha sido completamente reescrito. Publicó el parche contra 2.2.18 y superior, y reportó que en su máquina, ha estado corriendo desde Mayo 13 sin problemas.

David S. Miller recordó que Andrew Tridgell había notado este problema originalmente, pero por alguna razón que David no podía recordar, habían acordado no arreglarlo. Andrew replicó que Linus Torvalds había hecho la decisión. Andrew dijo, "Linus no quiso componerlo en pipe.c hasta que copy_from_user fuera compuesto en todas las arquitecturas" [...] "No quiso que nosotros compusiéramos solo este caso y después olvidar de componer el caso general."

Zack también replicó a David, preguntando porqué el problema había sido compuesto en 2.4 pero no en 2.2; en particular él preguntó, "¿Algún tipo de asuntos de compatibilidad?" David replicó crípticamente, "No, algún tipo de asunto "no importa"." Zack no estuvo de acuerdo, diciendo que el cambio creaba una situación donde el código del espacio de usuario podría comportarse diferente bajo 2.2 que 2.4; pero Linus replicó:

Hey, puedo demostrar que el código de usuario se comporta diferente dependiendo de que opciones de compilador fueron usadas etc.

Pista: "conducta indefinida".

Si alguien pasa un apuntador erróneo a una llamada del sistema, tan sólo ha invocado la regla de "el núcleo _puede_ ser bueno contigo, pero el núcleo podría sólo considerarte un idiota y decirte que funcionó".

No hay "datos perdidos" o algo más. Te has arruinado tú solo, y descartaste los datos. No culpes al núcleo.

Miles Lane dio un vínculo a una entrevista a Bill Gates en la cual Bill exponía su posición oficial sobre la GPL. Algunas gentes bromearon sobre Bill diciendo, "No conozco que alguien haya preguntado alguna vez por el código fuente de Word. Si lo hubiera, se lo hubiéramos dado. Pero no es una petición típica." Hubo algunos comentarios "Yo quiero una copia, Bill", hasta que Gerhard Mack remarcó, "Gracioso pero al dártelo pueden realmente arruinarte cuando llega al trabajo de código abierto. Si piensan que la GPL es viral no han visto "código compartido".. al menos la GPL solamente aplica a trabajos derivados." Y Miles dijo:

Ahí está la entrada. Fui al sitio de Microsoft y traté de encontrar una copia de su Licencia de Código Compartido o alguna aproximación en su lugar. Todo lo que pude encontrar fue un montón de charlatanería de Craig Mundie y algunas críticas a la GPL:

http://www.microsoft.com/business/licensing/sharedsource.asp

¿Cómo podemos evaluar si tiene sentido pedir a BillG el código fuente de Word si ni siquiera enseñarán la tiznada licencia? Lo que sospecho es que NO hay una "Licencia de Código Compartido". Y, aún si la hubiera, Microsoft no quiere que nadie la vea porque eso permitiría una comparación directa con la GPL, LGPL y así. ¡Que el cielo no permita que las manzanas sean comparadas con manzanas!

Lo que parecen tener es un mezcolanza de diferentes maneras de "compartir" código fuente.

Microsoft se da cuenta de qué derechos quiere permitir a cada uno de estas categorías de desarrolladores/usuarios y entonces restringe increíblemente la libertad de cualquiera que ve su código para cambiarlo, transportarlo o usar el código en cualquier forma después de todo. Mi impresión es que son felices de tener a estudiantes que vean el código de NT porque quieren a gente realmente lista que se acostumbre a usar NT todo el tiempo y después se gradúen y se conviertan en borgs de Microsoft.

Lo que imagino que sucece es que si pides el código fuente, ellos deciden qué es lo que quieren enseñarte, entonces te hacen firmar para renunciar a tu vida (como la libertad de trabajar en cualquier código vagamente parecido al código que te van a enseñar) y entonces te demandan hasta la bancarrota o en arreglos fuera de la corte si respiras en una forma que no les guste.

Finalmente Alexander Viro dijo que todo el tema era fuera de tópico, y el hilo de discusión terminó.

En el curso de la discusión, Linus Torvalds dijo acerca de un parche propuesto, "termina siendo un asunto de 2.5.x hasta donde me concierne (y no se preocupen, 2.5.x se ve como que se abrirá en una semana o dos, así que no estamos hablando de largos periodos de tiempo)."

Wan Hing Wah preguntó acerca del soporte a GPIB en Linux. Él había encontrado un controlador, pero la última versión parecía ser de 1999, y se preguntaba si alguien había hecho más recientemente. Richard B. Johnson replicó:

GPIB es terriblemente específico al dispositivo. ¿Qué tarjeta tienes intención de usar? National Instruments tiene un dizque controlador para su TNT4882 en su sitio web. Nunca pude siquiera compilarlo, mucho menos usarlo.

Tengo un controlador escrito para ese chip. No está bajo la GPL, pero puede estar si hay suficiente interés. En cualquier evento, te puedo enviar el código para intentarlo. Tan sólo no lo publiques aún. Déjame saber porque puedo usar entrada adicional para probarlo. En otras palabras, si me preguntan, puedo decir que solamente me estás ayudando a probar un controlador...

James Lamanna tiene un módulo 2.0/2.2 que había sido desarrollado por una compañía que ya no estaba en el negocio, y quería transportarlo a 2.4; él tenía todo el código, pero solamente preguntaba si existía alguna documentación en los varios asuntos de transporte existentes entre versiones anteriores y 2.4.

Timur Tabi sospechó que no había tal documento, pero Richard B. Johnson intentó:

Como un inicio:

wait_queue_head_t Ahora está definido. Puedes hacer '#if !defined(...)` y hacer cambios al código compatibles hacia atrás.

Macro, THIS_MODULE es ahora el primer miembro de struct file_operations.

Include <linux/init.h> el tipo de dato __init para inicialización de una vez de código o datos. Esto es nuevo, por lo tanto no es compatible hacia atrás.

La inicialización explícita de los spin-locks, SPIN_LOCK_UNLOCKED y/o spin_lock_init(spinlock_t *); Si compones esto, es compatible hacia atrás.

ioremap() y amigos son ahora requeridos aún para cosas de poca memoria. Puedes ya no tener más acceso a esto con un apuntador simple, debes usar readl()/writel(), etc., para una propia deferencia. Si compones esto, es compatible hacia atrás.

Estos cambios deben lograr que tu módulo compile (o casi).

Jonathan Corbet agregó que su nueva versión de "Linux Device Drivers" podría estar en una semana o dos (y disponible en la red poco después), y resolvería estos problemas de transporte o fallaría en su misión.

Albert D. Cahalan notó que el sistema de ficheros FAT32 era inesperadamente compatible con el algoritmo de Fase de Árbol, que permite ofrecer integridad completa de datos, mejor que los típicos sistemas de ficheros de jornadas. Daniel Phillips replicó, "Sí, FAT es lo que me inspiró para desarrollar el algoritmo. De cualquier forma, dos palabras: 'clusters perdidos'. Ahora que podría ser solamente un detalle de implementación ;-)" Albert replicó:

¿Cuáles clusters perdidos?

Establece el bit 8 de las "banderas" (A_BF_BPBExtFlags para Microsoft) para desactivar el espejo de FAT. Entonces los 4 bits bajos son un valor basado en 0 que indica qué copia de FAT debe ser usada.

Asume que tenemos 2 copias de FAT, como es (¿era?) común. Las llamaré X y Y. Cuando montamos el sistema de ficheros, desactivamos el espejo de FAT y marcamos la FAT X activa.

Ahora podemos hacer cambios a FAT Y sin afectar la integridad del sistema de ficheros. Windows no usará FAT Y. Como es usual en el algoritmo de árbol de fase, usamos el espacio libre para crear una nueva estructura a un lado de la antigua.

Tiempo para un cambio de fase:

Tenemos FAT Y, actualmente inactiva, actualizada en disco. FAT X está activa; describe el estado actual en el disco. Tenemos un directorio raíz nuevo en el disco, sentado en el espacio libre. Tenemos un nuevo sector de información del sistema de ficheros en el disco, sentado en el espacio libre.

Escribimos un sólo sector, entonces:

FAT X se vuelve inactiva, y no será usada por Windows. FAT Y se vuelve activa; describe el nuevo estado en disco. El directorio raíz antiguo es marcado como libre en FAT Y. ¡Bien! El sector de información del sistema de ficheros antiguo es marcado como libre en FAT Y. ¡Bien!

Una vez que el superbloque va a disco, FAT x también puede ser escrito.

Olivier Galibert preguntó, "¿Cuál es la Forma Correcta[mr] en 2.4.6 para alojar 16Mb como páginas de 4K y obtener la dirección de bus pci para cada página? Hay puntos de bono para que sean virtualmente contiguas, pero eso no es necesario. Si recuerdo correctamente, el viejo truco de vmalloc-entonces-recorre-las-tablas-de-página está considerado fuera-de-frontera en estos días." Alan Cox replicó, "Si lo quieres virtualmente contiguo entonces copia el código de bttv que aunque sea fuera-de-frontera u de otra forma se encuentra ahora en cerca de 8 controladores en el núcleo. Si no necesitas eso entonces puedes mapear espacio de usuario y usar kiovecs - que es mejor para muchas cosas." Riley Williams preguntó si sería bueno rehacer el código de bttv como una subrutina estándard que pudiera ser llamada por cada controlador que la necesitara, pero Alan sonrió socarronamente, "Podría pero entonces sospecho que Linus no querrá tomarlo porque podría impulsar a la gente a usarlo 8)"


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

1.	15 Jun 2001 - 22 Jun 2001	(4 posts)	Estado Del Soporte De EEPRO100/S
2.	17 Jun 2001 - 19 Jun 2001	(3 posts)	Nuevo Mantenedor Para Linux/PPC
3.	19 Jun 2001 - 22 Jun 2001	(20 posts)	Estado Del Soporte De VLAN
4.	19 Jun 2001 - 21 Jun 2001	(14 posts)	Preparándose Para 2.5
5.	19 Jun 2001 - 20 Jun 2001	(12 posts)	Cambios De Comportamiento Entre 2.2 Y 2.4
6.	20 Jun 2001 - 23 Jun 2001	(7 posts)	Microsoft Y Licencia Del Código
7.	21 Jun 2001 - 22 Jun 2001	(13 posts)	Linus Estima 2 Semanas Antes De 2.5.0
8.	22 Jun 2001 - 25 Jun 2001	(5 posts)	Estado Del Soporte De GPIB
9.	23 Jun 2001 - 26 Jun 2001	(7 posts)	Transportando De 2.0/2.2 A 2.4
10.	24 Jun 2001 - 25 Jun 2001	(5 posts)	¿FAT32 Bueno Para Jornadas?
11.	27 Jun 2001	(4 posts)	Alojando Memoria No Contigua

Tráfico del Núcleo #124 For 2 Jul 2001

Editor: Zack Brown

By Adam Buchbinder and Zack Brown

Translated By: Cristian Othón Martínez Vera