Tráfico del Núcleo #122 For 18 Jun 2001

There were 393 different contributors. 190 posted more than once. 152 posted last week too.

Derek Glidden dio una explotación para hacer que su máquina fuera enteramente irresponsiva por varios minutos. Él asoció esta conducta a la MV en 2.4, y agregó que él sentía que aún existían problemas serios antes de que la MV de 2.4 pudiera ser considerada estable. Otros confirmaron la conducta, y hubo una larga discusión. En un punto Miles Lane dijo, "Mike y otros, me estoy cansando de sus comentarios. Sheesh. Varios de los desarrolladores que trabajan actualmente en la MV ya han tomado en cuenta los casos y están explorando soluciones, incluyendo por lo menos un parche que ya existe. Parece claro que el clamor de la gente que está teniendo problemas con el nuevo manejo de la MV del espacio de intercambio ha sido escuchado y que las gentes van a arreglar esos problemas. Tal vez no suceda hoy o mañana, pero pronto. Diablos, ¿qué más quieren?" Derek replicó que su publicación original había sido con la intención de proveer algunos datos puntuales útiles, y Miles replicó, "De hecho, pienso que tu mensaje original fue útil. Ha estimulado una reevaluación de algunas suposiciones implícitas de diseño en la MV en las series 2.4 y también han emergido algunos errores. No eras tú quien yo sentí que estaba enviando comentarios inflamatorios, eran las gentes que han estado molestando como dolor de estómago acerca de los requerimientos actuales de espacio de disco para intercambio sin ofrecer ninguna información nueva para ayudar a los desarrolladores a remediar la situación. Así, gracias por traer el tema a discusión. :-)"

Ahora, esto puede muy bien ser cierto, pero lo que de hecho demostraste es que "swapoff()" es extemadamente (y quiero decir _EXTREMADAMENTE_) ineficiente, al punto que ciertamente puede ser llamado descompuesto. Se puso peor en 2.4.x no debido tanto a ningún empeoramiento de la MV genérica, como debido al hecho de que la conducta mucho más persistente del caché de intercambio en 2.4.x solamente expone las deficiencias fundamentales de "swapoff()" más claramente. No pienso que el algoritmo en sí de swapoff() haya cambiado, es sólo que el algoritmo siempre fue exponencial, creo (y debido al caché de intercambio persistente, la "n" en el algoritmo se volvió mucho más grande). Así que esto realmente es un problema separado de los asuntos de balanceo de MV en general. Ve y mira la lógica de "try_to_unuse()", y respinga. Amaría tener a alguien que vea un poco más a swap-off. Estaría bien, por ejemplo, que swap-off no notara correctamente las páginas de intercambio muertas después de todo - alguien debe verificar que no trate de leer y "try_to_unuse()" entradas de intercambio muertas. Eso debería hacer que la ineficiencia se mostrara aún más claramente.

Felix von Leitner reportó que algunos de los encabezados del núcleo causarían que las bibliotecas del espacio de usuario tales como dietlibc que dependen de ellos, exportaran la API incorrecta. Él mostró una compostura simple, pero David S. Miller replicó, "No usar encabezados del núcleo para espacio de usuario. Los encabezados del núcleo y los encabezados de usuario son espacios de nombres distintivamente diferentes, y has señalado solamente uno de tantos lugares donde usamos diferentes nombres/estructuras/etc. para algunos encabezados de red del núcleo vs. lo que el espacio de usuario quiere." Felix von Leitner se quejó, "¿Qué opción tengo? ¿Duplicar todo y entonces estar fuera de sincronía cuando las especificaciones cambien?" A lo cual Linus Torvalds replicó:

Sí.

Aún más preferible - escribe encabezados de espacio de usuario que tengan _solamente_ la cantidad mínima de código en ellos. Los encabezados del núcleo tienen mucha basura que es sólo del núcleo, y eso significa que si compilas en el espacio de usuario utilizándolos, tus compilaciones serán más lentas de lo que deben ser.

El asunto básico es que el núcleo se _negará_ a seguir las reglas del "espacio de nombres del día" de C89, C99, POSIX, BSD, SuS, GNU .. la lista continúa. Los encabezados del núcleo no son pensados para ser usados en el espacio de usuario, y no tendrán las estrictas reglas de espacio de nombres con los que muchos estándares gastan tanto tiempo jugando con ellas.

No hay tantas cosas que de hecho sean útiles en los encabezados del núcleo de cualquier forma. Muchas de ellos (como las cosas de IPv6) son realmente especificadas en otros lugares en primer lugar.

Peter J. Braam puso juntos algunos rpms de ext3 y los hizo disponibles en ftp://ftp.clusterfilesystem.com/pub/ext3. P.A.M. van Dam preguntó dónde podía encontrar el parche ext3 contra el núcleo 2.4, y Andrew Morton replicó:

Todos los detalles están en http://www.uow.edu.au/~andrewm/linux/ext3/

El estado actual es "bastante sólido". El rendimiento es bueno. Está básicamente sin probar contra LVM y RAID. Puede bloquear bajo cargas pesadas si estás usando cuotas de disco.

Evita esas cosas y no deberías tener ningún problema.

Transportarlo (hacia atrás) sobre las series -ac y componer los problemas de cuota son básicamente las siguientes actividades en la lista.

Dawson Engler escribió una utilidad para revisar el código fuente por bugs. Específicamente, dijo, "Pueden mirar a este revisor como esencialmente el rastreo donde la información de una fuente no confiable (p.e., de copy_from_user) puede alcanzar un vertedero confiable (p.e., un índice de una matriz). El factor limitante principal en su efectividad es que tenemos una noción muy incompleta de vertederos confiables. Si alguien tiene sugerencias para otros lugares generales donde es peligroso consumir datos malos, por favor envíeme un email." Él enumeró quince bugs que había descubierto con su herramienta. Alan Cox rápidamente parchó varios de ellos, y Oliver Xymoron agregó:

Yo escribí algo similar a esto para espacio de usuario (vía precarga de ld). La mayor parte de mis revisiones siguieron cadenas de texto alrededor y se aseguraron de que fueran revisadas sus longitudes para evitar desbordamientos de la pila, pero también revisé argumentos a open, etc..

En tu caso, básicamente todos los destinos son vertederos confiables en algún nivel: el espacio de usuario te da datos para poner en algún lado. Quisieras en vez de eso revisar que los datos están pasando a través de funciones que 'desmanchen', revisando capacidades, etc. Apuesto que encontrarás que algo así como que el 90% de las rutas del código están cubiertas por algunas cuantas revisiones de seguridad comunes. Y que la mayoría del resto pueden ser reescritas para tenerlas.

Eric S. Raymond reportó el hallazgo de varios símbolos de configuración nuevos en 2.4.6pre2 que no tenían documentación correspondiente. Los enumeró:

Maksim Krasnyanskiy reclamó los elementos CONFIG_BLUEZ, diciendo que pertenecían al subsistema Bluetooth, agregando que Linux era el primer SO en tener soporte oficial para Bluetooth. Él describió estas opciones:

CONFIG_BLUEZ

Bluetooth es una tecnología inalámbrica de corto alcance, baja energía y bajo costo. Fue diseñada como un reemplazo para cables y otras tecnologías de corto alcance como IrDA. Bluetooth opera en rangos de área personal que típicamente se extienden hasta 10 metros. Más información acerca de Bluetooth se puede encontrar en http://www.bluetooth.com

El subsistema Bluetooth de Linux consiste de varias capas:

Núcleo HCI (administrador de dispositivo y conexión, calendarizador)
Controladores de dispositivo HCI (interfaz al hardware)
Módulo L2CAP (protocolo L2CAP)

Diga Y aquí para activar el soporte de Bluetooth para Linux y para construir la capa del Núcleo HCI.

Para usar el subsistema Bluetooth de Linux, necesitará varias utilidades de espacio de usuario como hciconfig y hcid. Estas utilidades y actualizaciones a los módulos Bluetooth del núcleo se proveen en el paquete BlueZ. Para más información, vea http://bluez.sf.net.

Si quiere compilar el Núcleo HCI como módulo (hci.o) diga M aquí.

¿ No está seguro ? diga N.

CONFIG_BLUEZ_L2CAP

L2CAP (Protocolo de Control y Adaptación de Enlace Lógico) provee transporte de datos orientados a conexión y sin conexión. El soporte de L2CAP se requiere para la mayoría de las aplicaciones Bluetooth.

Diga Y aquí para compilar el soporte a L2CAP en el núcleo o diga M para compilarlo como módulo (l2cap.o).

¿ No está seguro ? diga M.

CONFIG_BLUEZ_HCIUART

Controlador de UART HCI de Bluetooth. Este controlador es requerido si quiere usar dispositivos Bluetooth con interfaz de puerto serial.

Diga Y aquí para compilar el soporte para dispositivos UART de Bluetooth en el núcleo o diga M para compilarlo como módulo (hci_uart.o).

¿ No está seguro ? diga M.

CONFIG_BLUEZ_HCIUSB

Controlador USB HCI de Bluetooth. Este controlador se requiere si quiere usar dispositivos Bluetooth con interfaz USB.

Diga Y aquí para compilar el soporte para dispositivos USB de Bluetooth en el núcleo o diga M para compilarlo como módulo (hci_usb.o).

¿ No está seguro ? diga M.

CONFIG_BLUEZ_HCIEMU

Dispositivo HCI virtual de Bluetooth. Este controlador es requerido si quiere usar software de emulación HCI.

Diga Y aquí para compilar el soporte para dispositivos HCI virtuales en el núcleo o diga M para compilarlo como un módulo (hci_usb.o).

¿ No está seguro ? diga M.

Randy Dunlap sugirió decir "¿Seguro? diga M" en lugar de "¿No está seguro? Diga M", y Maksim coincidió y publicó una lista revisada poco después.

Matt Nelson tenía un proyecto que requería cerca de 6G de RAM bajo Intel, y quería saber si había algunas advertencias de las que debía estar prevenido. Doug McNaught sugirió conseguir una máquina Alpha, y explicó, "Los apuntadores en IA32 aún son 32 bits, así (como lo entiendo) cada proceso puede direccionar un máximo de 4GB. Podrías alojar múltiples fragmentos (en memoria compartida o en ficheros mmap()eados, así son persistentes) y mapearlos de entrada o salida según fuera necesario (lo cual se volvería peliagudo)." Pero agregó, "si puedes dividir tu tarea en procesos múltiples tales que ningún proceso requiera direccionar más de 4GB, una máquina IA32 trabajará bien." Después Matt dijo, "Gracias a todos los que respondieron. Nunca había necesitado usar tanta memoria antes, y era ignorante en cuánta magia fue implementada en el soporte a 64G en IA32. Desafortunadamente, no hay aún suficiente magia ahí para mis necesidades... ahora para encontrar un sistema Alpha SMP asequible...."

Craig Lyons de Promise Technology envió un parche a Andre Hedrick, explicando, "En el núcleo 2.4 hay soporte para algunos de nuestros productos (Ultra 66, Ultra 100, etc.). Como algunos sabrán o no, nuestra familia Ultra de controladores (que son sólo controladores IDE estándard y no tienen RAID) usan el el mismo ASIC en ellos que nuestros controladores FastTrak RAID usan. El núcleo 2.4 reconocerá nuestra familia Ultra de controladores, pero hay un problema en ellos en que un FastTrak no será reconocido como un FastTrak, sino como un Ultra. Consecuentemente, la matriz en el FastTrak no será reconocida como una matriz, sino cada disco será visto individualmente, y los datos de los usuarios no seran accesados adecuadamente. Tenemos un parche que compone esto y nos preguntábamos si sería posible incluir este parche en el núcleo." Andre replicó, "No quiero ni necesito los parches de su compañía, punto. No tomaré o aceptaré o aprobaré ningún código sucio que permite que un controlador binario pobremente escrito que no puede controlar sus ISR y que interfiera irresponsablemente con el controlador ATA nativo."

Bert Hubert lo corrigió, "Craig te contactó para encontrar qué estaba mal y deberías explicarle cuáles son los problemas, y cómo los podría resolver. Linus aceptaría parches escritos por Bill Gates si tuvieran la licencia correcta y propiamente escritos, así que no veo porqué Promise sería una excepción." Él también explicó a Craig, "El procedimiento es publicar el parche públicamente y tener a la gente comentando y probándolo. Con frecuencia encontrarán que su código no está a la par o hace cosas en formas que no complacen a la gente del núcleo. No hay la intención de ningún mal, es sólo que los desarrolladores del núcleo son un grupo puntilloso. Pero dado la punzada correcta les dirán como podrían cambiar su código para que sea aceptable. Alternativamente, la gente de aquí podría ver que necesita ser hecho en su parche, y hacerlo ellos mismos." Pero Andre dijo, "No no tomaré su código ni lo aplicaré. Ni siquiera quiero verlo. Todo lo que queremos son las reglas API para las firmas y las tenemos ahora. No necesitamos su controlador." Rob Landley sintió que, como un mantenedor, Andre debía ser más "abierto" sobre sus parches. Andre replicó, "He visto una versión y me puse físicamente enfermo."

Quisiera publicamente agradecerte por venir a la mesa de GNU/GPL con una perspectiva abierta. Después de 90 minutos en el teléfono, de los cuales 45 minutos fueron yo señalando asuntos problemas y quejas con 20 minutos en formas de trabajar en soluciones en el cercano y distante futuro y la escucha a sus preocupaciones y preguntas entre mis momentos de interrupción.

La próxima conversión no tendrá los momentos explosivos porque será en persona o la batería de mi celular tendrá carga completa.

Desde que afirmaste "no haré promesas que no puedo mantener" esto es algo bueno y será un camino justo para limpiar conflictos del pasado por ambas partes.

Buscaré que Promise trabaje con Linux en formas significativas y productivas.

Por favor responde y corrige cualquier cosa que esté mal establecida por mí o verifica la veracidad. Esto mostrará un acto de buena fe ante todos los que observan esto.

Andre y yo de hecho tuvimos una buena conversación en el teléfono. Gracias de nuevo por tomar el tiempo de hablar conmigo y ofrecerme tu apoyo. Como afirmé en el teléfono, estamos haciendo un gran compromiso de recursos para dar soporte a Linux liberando controladores y utilidades para nuestros productos, incluyendo el FastTrak. Sé que tenemos planes de liberar código fuente para nuestras series de tarjetas Ultra y SuperTrak, pero en este punto no estoy seguro si la forma en que vamos a estar soportando FastTrak es lo que les gustaría ver. Como dije, mientras no pueda garantizar nada en lo que no tenga la autoridad de entregar, pasaré sus peticiones. Trataré de ser un promotor de Promise en la comunidad Linux, y un promotor de la comunidad Linux en Promise. Si la compañía tiene preocupaciones, les haré saber cuáles son, y tal vez nos puedan decir si estamos fuera de lugar con esas preocupaciones o no.

Quisiera invitar a cualquiera a contactarme si tienen cualquier sugerencia, cualquier petición, lo que sea. Como le dije a Andre, no prometeré algo que no pueda entregar personalmente, pero haré todo lo que pueda para ayudar. También estoy tratando de obtener un punto de contacto técnico para que no tengan que lidiar con un empleadillo de mercadotecnia que no entiende la mitad de lo que están diciendo ;).


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

1.	5 Jun 2001 - 12 Jun 2001	(150 posts)	Estado Del Subsistema De Memoria Virtual De 2.4
2.	8 Jun 2001	(6 posts)	Usando Encabezados Del Núcleo En Programas De Usuarios
3.	8 Jun 2001 - 9 Jun 2001	(4 posts)	Estado De ext3
4.	8 Jun 2001 - 11 Jun 2001	(10 posts)	Cazador de Bugs Automático
5.	10 Jun 2001 - 13 Jun 2001	(4 posts)	Símbolos De Configuración Sin Documentar En 2.4.6pre2
6.	11 Jun 2001 - 13 Jun 2001	(9 posts)	Limitaciones De Bigmem
7.	12 Jun 2001 - 13 Jun 2001	(10 posts)	Parches Comerciales

Tráfico del Núcleo #122 For 18 Jun 2001

By Zack Brown

Translated By: Cristian Othón Martínez Vera