Tráfico del Núcleo #98 For 18 Dec 2000

Muchas gracias para Martin Josefsson y el resto de la gente en #kernelnewbies por sacarme de un apuro. Fui sacado de linux-kernel por mensajes rechazados (larga historia), y para cuando pude resuscribirme ya había perdido un bloque significativo de material. Fui a #kernelnewbies y arriba-y-abajo, varias gentes me ofrecieron ayuda y consejo. Martin comprimió un archivo grande y me lo envió. ¡*fiu*! ¡Gracias, Martin y gente!

There were 368 different contributors. 156 posted more than once. 129 posted last week too.

James Lamanna reportó buen éxito con el controlador para Fasttrack 100 de Promise Technologies (disponible como código fuente, con un fichero objeto propietario). Él preguntó si era posible compilar el módulo directamente en el núcleo, así su sistema podría detectar automáticamente su tarjeta. Agregó, "Un simple enlace del módulo en la biblioteca scsi a través de editar el Makefile no parece lograrlo. No detecta las unidades si arranco de un floppy con este núcleo en él." Andre Hedrick replicó fuertemente:

¡NO!

Hacer eso VIOLA los términos y acuerdos que obtuviste [con] el Engine Soft-Raid BINARIO y los términos GPL del núcleo.

Henning P. Schmiedehasen trató de corregirlo, diciendo que la única violación sería si James entonces intentara distribuir el resultado. Dijo, "Puedes compilar en tu kernel todo lo que quieras mientras no lo distribuyas."

André reviró con, "¡recuerden, YO DEFINÍ los términos en los que el módulo puede ser creado! Ve y examina la envoltura y tiene porciones del código de pdc202xx.c que es mío. Con eso en mente, para usar ese código GPL, las restricciones y términos impuestos fueron módulo exclusivo."

Con respecto a la cuestión GPL en general, el Dr. Kelsey Hudson no estuvo de acuerdo con Henning, diciendo que al modificar un código fuente GPLeado requería que el usuario distribuyera el resultado. Dijo, "No puedes agregarle cosas y luego no distribuirlo, eso está en violación." Alan Cox replicó, "No no lo es. Algunas personas parecen pensar que sí. Tú sólo tienes que proveer un cambio si le diste a alguien los binarios concernientes. Algunas personas también piensan que las cláusulas de 'enlace' significan que ellos pueden tan sólo dirigir al cliente a hacer el enlace, y eso también podría aparecer ser falso en un precedente legal - la ley se preocupa por el intento." Pavel Machek replicó, "Esto está sucediendo actualmente con el controlador de winmodem lucent: tiene una versión modificada de serial.c y se pide a los clientes que lo compilen y lo enlacen (estáticamente) contra el código propietario para obtener un controlador usable. ¿Eso está bien o no?" Alan sintió que probablemente no, pero agregó que estaba realmente en manos de Theodore Y. Ts'o para hacer valer o no. Y Ted dijo extensamente:

Bueno, no está todo en mí, dado que Linus también tiene su copyright en el código (aunque yo dudo que haya más de unas cuantas líneas de lo que es originalmente suyo). Hay algunas otras gentes que han contribuído código al controlador serial en el pasado, aunque la mayoría probablemente no me ha dado más de una docena de linea de código o algo así, lo cual parece ser el (completamente sin probar en la corte) estándar que usa la FSF para decidir si necesita o no tener papeles legales firmados.

Los asuntos legales también son increíblemente turbios, porque los clientes crean el trabajo deriviado, y haciendo a un lado los asuntos de intento, no necesariamente usas intento para cambiar la definición legal de "trabajo derivado". (Alégrense; a pesar de que puede ser usado para crear un vacío legal en la GPL, tan solo mediten un rato sobre lo que la MPAA puede hacer con tal argumento de "intento" antes de que decidan si es o no una cosa buena. O piensen sobre lo que Microsoft podría hacer si ellos pudieran hacer su EULA tan infecciosa como la GPL con el argumento de "intento".) Todo el argumento de enlace dinámico es una pendiente muy resbalosa; ¿en dónde pintas la raya? ¿Un guión shell que llama a un programa GPL queda infectado? ¿Qué hay acerca de un programa propietario en C que hace una llamada a system() para invocar a un bash GPLeado? ¿Que hay sobre una llamada de RPC a través de la red? ¿Qué hay sobre una interfaz Corba de GNOME? Está OK si está en máquinas separadas, pero ¿son consideradas como un sólo programa si el cliente CORBA y el servidor están en la misma máquina, ya que comparten la misma VM?

En cualquier caso, la FST tiene su opinión, y por lo menos un profesor de leyes de la Ivy League se carcajeó cuando se le preguntó lo que él pensaba acerca de las teorías legales de la FSF; otras gentes tienen la suya propia. Lo más importante, ninguna de éstas ha sido probada en la corte. Así que probablemente no tiene sentido tratar de arreglar esto en la lista linux-kernel.

Con respecto a lo que este caso en particular le concierne, por lo menos Lucent está distribuyendo parte de su controlador en código fuente. Algunos de los otros controladores winmodem son distribuídos como módulo binario puro, lo cual significa que solamente funcionarán contra una version de núcleo única, lo cual asegura a los usuarios en contra de actualizar a núcleos nuevos si aún quieren usar su winmodem. Así por lo menos Lucent está tratando de ser por lo menos algo de chicos buenos acerca de esto.

Podría amenazar con demandarlos, pero no está claro para mí que bien haría, menos de privar a algunos usuarios de poder usar sus winmodem. Sopongo que podríamos animarlos a reescribir el serial.c modificado desde nada, pero más allá de hacer sentir bien a algunos fanáticos de la GPL, enriqueciendo a algunos consultores y hacer a Lucen un poco más pobre, ¿qué bien realmente hace en el largo plazo? Y tengo cosas mejores que hacer con mi tiempo. Al mismo tiempo, ciertamente no bendeciría lo que están haciendo. Lo que están haciendo es claramente incorrecto e ilegal. Pero es un mundo imperfecto en el que vivimos, como los eventos en Florida lo han demostrado claramente durante el mes pasado.

Dado el limitado tiempo que tengo, preferiría emplearlo en ir tras el controlador de winmodem Rockwell/Connexant, que también de forma muy clara usa serial.c, pero para el cual solamente han distribuido un sólo fichero .o para una versión específica del núcleo. O podría emplearlo en programar.....

A las especulaciones en el segundo párrafo de Ted de arriba, Jeff V. Merkey replicó:

Bajo la "Doctrina de la Revelación Inevitable" aún revisando el código GPL y usando las técnicas que contiene contaminaría cualquier cosa que en la que cualquiera trabajara. Esta doctrina utiliza dos conceptos que han sido usados en casos de tratados secretos para justificar intromisiones y no-competencias en áreas de contaminación de Propiedad Intelectual -- conocimiento negativo y apropiación indebida inevitable.

El argumento va algo así. El conocimiento negativo es definido como saber qué técnicas no funcionan (opuesto a qué técnicas funcionan). En el curso del desarrollo de una pieza de software, hay muchos "callejones sin salida" y "falsos inicios" que son encontrados mientras un individuo usa ensayo y error para perfeccionar cualquier pieza de software que esté escribiendo. Con el tiempo, la persona aprende qué acercamientos son callejones sin salida y cuáles funcionan. Este conocimiento se queda impreso en los procesos actuales de pensamiento de esta persona.

El código fuente también puede contener notas y comentarios acerca de lo que no funciona, y qué funciona. Alguien leyendo este código fuente entonces incorporaría estas ideas y conocimiento en sus procesos de pensamiento. Las compañías gastan grandes cantidades de dinero pagando a los ingenieros para desarrollar software, y este "conocimiento negativo", bajo la doctrina de revelación inevitable es legalmente la propiedad de un empleador ya que ellos pagan a un ingeniero para que experimente y lo aprenda. Así es como las compañias pueden obtener órdenes de la corte de no competencia contra los empleados en demandas de tratados secretos -- ellos argumentan que nadie detendrá una ruta de desarrollo usando ideas o aproximaciones que saben que no funcionan. Este argumento continúa en establecer que si dos ingenieros, uno que tuvo acceso a una pieza de código vs. uno que no pudo comenzar a trabajar al mismo tiempo trabajando en el mismo problema, la persona que tuvo acceso al código terminaría primero por pudo "inevitablemente usar" el conocimiento adquirido del acceso al código fuente.

Digamos por ejemplo que dos ingenieros quieren escribir un nuevo reemplazo parecido a Linux. Uno de ellos tuvo acceso a ftp.kernel.org y el otro no. ¿Cuál de los ingnieros terminaría primero? Obviamente el que tuvo acceso a ftp.kernel.org terminaría primero y no tendría que haber usado ensayo y error para lograr que todas las llamadas IOCTL funcionaran, etc. El ingeniero sin acceso al código fuente le tomaría más tiempo, tal vez por un factor de años, para completar el mismo proyecto.

Bajo este argumento, se argumento que el ingeniero que tuvo acceso al código fuente "inevitablemente usó" conocimiento negativo que obtuvo de su estudio de las fuentes de Linux. Ausentes las vagas descripciones de lo que es un "trabajo derivado" en la GPL, se puede argumentar que la conversión de cualquier conocimiento contenido en código GPL es un "trabajo derivado".

Hay muchas compañías grandes de software que creen esto y temen la aplicación de la doctrina de la revelación inevitable relativa al código GPL. Tanto Novell y Microsoft no permiten a los empleados siquiera llevar código GPL dentro del edificio -- punto -- por tempor de que alguien intentará archivar un reclamo de que ellos habían "convertido" código GPL y creado trabajos derivados que puedan haber contaminado proyectos de código no GPL. Novell tiene una política oficial vigente que salva a los empleados de usar código GPL. Eso es por qué todo el trabajo de Linux para NetWare es hecho en el centro de desarrollo de la India, y no en EUA, fuera del temor de contaminación de Propiedad Intelectual en la instalación de Provo. Cuando tuve oficina en el campus de Microsoft en 1999, tenían políticas similares, y eran aún más estrictas que las de Novell.

Ahora, en la realidad, esas gentes tienen empleados en ambas compañías que transfieren cosas en casa, y juegan con eso, código GPL incluido, pero es muy diferente para estas compañías teniendo políticas oficiales permitiendo proyectos que usen código GPL en su curso normal de negocios.

En breve, bajo la doctrina de revelación inevitable, un poseedor de copyright GPL puede tener éxito con un reclamo de conversión de alguien que simplemente miró una pieza de código GPL, y después usó cualquier cosa que contuviera para construir ya sea una interfaz de módulos o un módulo con funcionalidad similar. Sería una llamada difícil de hacer para un juez sentado, pero he visto casos actuales donde un juez tan sólo lo hace con la ayuda de un experto especial.

Personalmente, pienso que la doctrina es una de las más malignas cosas de mierda en existencia, los oponentes legales la llaman "la doctrina de la esclavitud intelectual" porque tiene ese efecto bajo la ley de ser capaz de convertir simples acuerdos de NDA en acuerdos de no competencia, y lo he visto ser usado en esa forma. Novell ha bloqueado todos sus accesos internos al servidor de ftp NWFS TRG, por cierto, porue ellos están temerosos de que yo intente aplicar la doctrina para forzarlos a abrir el código fuente de proyectos de Novell si ellos descargan NWFS y lo usan internamente con eDirectory. Nos lo han dicho también.

Esto puede ayudarles a entender que tan complicadas son todas las cosas de Propiedad Intelectual relativas a trabajos derivados. Está indefinido bajo los casos legales actuales y precedentes relativos a la GPL, pero estas grandes compañías no toman riesgos....

Más tarde, agregó, "Dicho sea de paso, para aquellas gentes del campo legal que también demandan publico citas de casos de ley, por favor vean el caso Pepsico vs. (olvidé el nombre de las personas). Tan sólo entren en Westlaw, y busquen "Pepsico". Es el caso donde esta doctrina fue creada y aplicada por un juez del estado. El caso fue mantenido, y ha sido usado por todo EUA desde entonces para criticar a empleados que parten de grandes compañías de software/hardware."

En respuesta a la afirmación de Jeff acerca de comvertir NDAs simples en no competencias, Ted replicó, "la mayoría de las cortes tiene límites estrictos sobre qué tan lejos tomarán los argumentos de no competencia, y si una NDA convertida en una no competencia, pasado un cierto punto dirán que una persona tiene derecho para ganarse la vida..... Afortunadamente la mayoría de los jueces aplicarán alguna cantidad de sentido común, aún a pesar de su entrenamiento en la escuela de leyes. En cualquier caso, la GPL no involucra NDA's o Tratados Secretos, así que decir que esta doctrina podría ser usada para contaminar código no GPL simplemente por tener gente mirando código GPL es mierda." Jeff replicó, "Este argumento de "yo tengo derecho de ganarme la vida" solamente se sostine si el otro lado se niega a publicar un bono. Si ellos publican un bono lo suficientemente grande, una corte FALLARÁ en favor de la inevitabilidad si hacen un buen caso para eso. (El bono requerido para mantenerme fuera de programar por 18 meses le costó a Novell $10,000,000.00.)" Con respecto al sentido común de los jueces, añadió, "Todos los jueces de EUA son poncios pilatos -- con corazones tan negros como las túnicas que usan. No se preocupan por tí, o tus derechos. Recuerda, casi todos los jueces son abogados que son muy viejos o muy incompetentes para practicar la ley así que se ponen ellos mismo una cita. La mayoría de ellos fueron abogados corruptos que entraron en la política (que es como un abogado se convierte en juez, por cierto, entra a la política)."

2. Cazando Varios Bugs De Corrupción Del Sistema De Ficheros: La Saga Continúa

Continuando de BROKEN KCREF, Andries Brouwer reportó, "Hice de nuevo una gran prueba comparando dos árboles idénticos. Encontré de nuevo corrupción, y, después de inspeccionarlos, los ficheros de disco no difieren - es corrupción en el núcleo solamente." Linus Torvalds preguntó por un estimado aproximado de cuándo Andries comenzó a ver esta conducta, y Andries replicó, "He reportado ambos casos. Esto es, lo comencé a ver hace unos días." Linus replicó:

No estaba tratando de implicar que no los hubieras reportado bien.

Es solamente que nací con un caso muy desarrollado de Altzheimers, y tengo problemas manteniendo los detalles en mi cabeza por más de cerca de cinco minutos.

Soy medio serio, por cierto. No es que no tenga una buena memoria, pero tiendo a recordar patrones y cómo funcionan las cosas, y soy _realmente_ malo para mantener la pista de los detalles. Esto es por qué dependo absolutamente de gente como Alan Cox etc que mantienen listas de problemas, y que son buenos en recopilar reportes en qué tipos de máquinas lo ven etc. Yo sólo apesto en eso. De verdad lo hago.

De cualquier forma, tentativamente suena como que podría haber corrupción de request por el nuevo código remezclado. Coinciden los detalles, tienes IDE y todo. Veo que no puedes al menos fácilmente reproducirlo en pre3 más, pero si aparece después entonces aún puedes, por favor aullar. Fuerte.

Esto aún deja la corrupción SCSI, que no puede haber sido por el asunto de request. ¿Cúal es el patrón aquí para la gente?

En otro lado, Andries reportó, "Acabo de intentar 2.4.0test12pre3, que tiene la compostura de Jens, y no hay corrupción que sea vista. Probaré un poco más, pero tal vez esto lo hizo." Tigran Aivazian lo intentó en su sistema SCSI, pero Jens Axboe explicó, "No, la compostura solamente puede hacer una diferencia en IDE. Así que posiblemente no puede tomar contar para todos los asuntos de corrupción reportados, pero espero que por lo menos algunos de ellos... La compostura fue publicada en el otro hilo de corrupción, y está en test12-pre3 también."

En discusiones técnicas en otro lado, un montón de gentes trató de rastrear los varios problemas.

Patrick van de Lageweg publicó un parche para permitir que un demonio de espacio de usuario maneje las partes internas de un puerto serial. Agregó, "Fue escrito para el Servidor RAS Pele 833 pero también es usable por otros controladores de dispositivos seriales en espacio de usuario." Pavel Machek remarcó, "Bien, finalmente alguien implementó esto. Esto va a ser obligatorio si queremos dar soporte a winmodems adecuadamente; también la gente de ISDN estaría interesada [para patear la emulación AT fuera del núcleo]" Y Jamie Lokier añadió, "Para los winmodems puedes hacer un muy buen trabajo con ptys -- el lado pty y tty acceden a la misma estructura compartida de termios. El nuevo controlador es una forma mucho más limpia hacia la misma funcionalidad de cualquier manera."

De todas maneras, Tigran Aivazian señaló algo de exceso en el parche, donde las variables eran iniciadas explícitamente a cero, en lugar de dejarlas que tomaran un valor inicial 0 del área de BSS, la cual el núcleo limpió automáticamente en el arranque. Explicó que el código como estaba "desperdicia al menos 4 * USSP_MAX_PORTS bytes en la imagen del núcleo. Típicamente cerca de 64 bytes pero podrían ser más. Para más información vean las recientes guerras de flamazos tontas en la lista." Rogier Wolff regresó con, "Y yo pienso que los tipos que estaban diciendo que la "documentación es más importante que estos cuantos bytes" estaban ganando." Argumentó que el establecer el valor inicial nulo explícitamente, daba información importante a los que mantienen el código. En un punto Russell King argumentó en respuesta " En ese caso, ¿lo podemos poner como una compostura en la documentación en lugar de cambiar la salida del compilador?" El sugirió simplemente incluir un comentario al efecto de que se esperaba que las variables fueran cero inicialmente. Esto no le agradó a Rogier, quien replicó:

Tengo más cuidado sobre los 4 bytes de código fuente extra que de los 4 bytes de objeto extra.

Considero los 4 bytes de código objeto extra un bug del compilador, y si comenzamos a cuidarnos de eso, el bug en el compilador nunca será compuesto.

Esto es similar a cómo Linus forzó el reconocimiento del bug de "unroll-loops" por parte del equipo gcc.

4. Problemas Con La Limpieza De Código De Sonido Propuesta En Las Series Estables

Este parche hace los mismos cambios (dma_prog y poll) que ya están hechos para algunos otros controladores OSS (test12-pre3). Más allá finalmente incluye todas las modificaciones hechas en 2.2.18 (Alan: ¿ por qué las haces línea por línea ?).

Implementa salida mono y compone un bug en la lógica de dma (reiniciación necesaria porque algunos descriptores ya han sido pretomados y no son actualizados cuando el dma es sólo detenido y no reiniciado). Hay aún un bug en el manejo del cerrado del dispositivo, da un error de overrun de dma ocasional.

Ha sido probado por 3 personas en 4 máquinas diferentes con 3 juegos de chips diferentes y por lo menos 3 codecs diferentes, así que ¡ realmente debe funcionar ! Y hace las mismas cosas que el controlador alsa hace.

Alan Cox pidió a Linux Torvalds no aplicar el parche, diciendo, "No solamente hace conversiones de formato en el núcleo (que es un estricno no debe ser hecho en la política de controladores de sonido) también hace imposible que funcione mmap correctamente con las definiciones de API de OSS." Agregó, "Tjeerd. Yo deliberadamente apliqué solamente pequeños pedazos de tu parche antes porque la cosa del modo mono atasca el controlador horriblemente y no está en el lugar correcto. Pertenece a las aplicaciones/bibliotecas." Pavel Machek replicó que en ese caso, partes de drivers/usb/audio necesitaban ser borradas también, ya que también contenían conversiones de formato. Alan replicó, "Definitivamente debemos." En este punto Thomas Sailer interrumpió, argumentando:

Si empiezas a matar conversión de formatos entonces >99% de las aplicaciones existentes no funcionarán nunca más con usbaudio. En este punto puedes desechar la interfaz OSS también.

Y antes de matar la conversión de formatos debes matar el desarrollo de mmap porque la complejidad de la conversión de formatos (~25 Líneas De Código) es por mucho rebasada por las cosas de emulación de mmap.

La pregunta subyacente es:

queremos un controlador de audio usb que da soporte a la interfaz OSS y con el cual la mayoría de las aplicaciones existentes funcionan
o queremos un controlador simple con su propia interfaz que no es OSS.

Cualquier cosa en medio es EMO tonta. Matar la conversión de formatos tira la ventaja de correr muchas aplicaciones existentes pero no te lleva mucho más cerca a la meta de simplicidad.

Esas aplicaciones ya tiene que trabajar con el hecho de que algunos dispositivos solamente soportan audio estéreo 48KHz 16bit. Corro un ambiente de escritorio completo con ese hardware sin problemas.

Cual formato es el que causa los problemas, el único formato clave mal soportado ahora que yo sepa es 16bit bigendian. Eso necesita algunos pequeños parches para esd.

A lo cual Thomas replicó, "S8 no es un formato con no muy buen soporte. Y de hecho hay muchas aplicaciones que no pueden vivir con esd por razones de latencia." Fin de la discusión.

5. Pánico de Núcleo En La Autodetección De SoftwareRAID Autodection En Núcleos Recientes De Desarrollo

Roberto Ragusa reportó que en núcleos de desarrollo recientes (2.4.0-test10 y 2.4.0-test11), el código de autodetección de SoftwareRAID daba un pánico de núcleo. Él incluyó mucha información del sistema y salida de oops, etc., y Neil Brown rápidamente replicó que eso había sido compuesto en 2.4.0-test12pre3; Roberto reportó que no, el problema persistía en ese núcleo también. Neil lo revisó más detenidamente, y replicó

Mis disculpas. Había un "oops en autodetección de SoftwareRAID" en test10 y test11 que fue compuesto en test12pre3, y tan sólo asumí que el tuyo era el mismo, y no lo observé adecuadamente.

Revisando de nuevo, tu problema es definitivamente diferente y bastante extraño.

Incluyó una compostura de una línea y agregó, " Regresé y revisé a grandes rasgos el código por un pequeño rato y pienso que encontré algo. linear.c podría sobreescribir una memoria temporal reservada con kmalloc, que podría producir exactamente lo que estás obteniendo. El siguiente parche no es *correcto*, pero si hace una diferencia para tí, entonces significa que hemos encontrado el problema.. por favor házmelo saber."

Roberto replicó felizmente, "Sí, hace una diferencia :-) . El arranque ya no falla más y todas las particiones RAID son detectadas correctamente." En este punto la discusión se disolvió.

Steven N. Hirsch reportó que 2.2.18 detecta un ratón PS/2 no existente en su sistema. Alan Cox replicó, "He compuesto el caso mayor." [...] "Lo tomo como los otros 2.4test que también reportan erróneamente un ratón PS/2 estando presente. De cualquier forma pienso que ya no es más crítico para 2.2.18. Alguien con una tarjeta madre existente puede juntar el rompecabezas." Jeff V. Merkey reportó que problema se fúe en 2.2.18-24. Steven no fue tan afortunado, y aún reportó el mismo problema, aunque añadió, "Coincidio en que la detección incorrecta del ratón no es crítico - tan sólo una maldita molestia."

Varios días después, bajo el Subject: 2.2.18-25 and PS/2 Mouse, Steven reportó la persistencia de problemas de ratón fantasma en 2.2.18-pre25; pero nada salió de eso.

K Ratheesh, estudiante del Instituto de la India de Tecnología Madras, anunció:

Estoy trabajando en habilitar la consola Linux para lenguajes Locales. Como el formato PSF actual no soporta tipografía de ancho variable , he hecho un parche en el controlador de la consola que cargará una tabla de mapeo multi-glifos definida por el usuario así que múltiples glifos pueden ser mostrados para un sólo código de carácter. Todas las operaciones de edición también deberán tener cuidado de esto.

Además, para lenguajes de la India, hay varios modificadores consonante/vocal que resultan en agrupaciones de caracteres complejas. Así que he extendido el parche para cargar reglas de decodificación sensitivas al contexto definidas por el usuario para códigos de glifo / carácter también. De nuevo, todas las operaciones de edición se comportarán de acuerdo a las especificaciones de las reglas de decodificación.

Aunque a pesar de que el parche ha sido desarrollando con lenguajes de la India en mente, siento que será aplicable a muchos otros lenguajes (por ej. Chino) que requieren tipos de letra más anchos en consola o decodificación definida por el usuario a nivel E/S.

Actualmente he desarrollado el parche para versiones del Núcleo 2.2.14 y y estoy en el proceso de hacerlo para 2.2.16 y 2.2.17. Pido que la gente pruebe este parche y me dé comentarios y sugerencias.

Aquellos que quieran intentar este parche pueden enviarme mail a la dirección rathee@lantana.iitm.ernet.in o aindlinux-iitm@lantana.iitm.ernet.in

El paquete , que contiene el parche , algo de documentación ,herramientas y archivos de ejemplo es cerca de 100 KB.

Andries Brouwer estaba feliz de oír acerca de esto, y agregó, "El año pasado necesité dar soporte para Tibetano y agregé solamente lo converso: glifos sencillos que eran representados por una secuencia de símbolor Unicode. Esto es necesario p.e. en la situación donde Unicode no tiene símbolo+diacrítico precombinado, así que el glifo que representa un carácter acentuado corresponde a una secuencia en lugar de un símbolo Unicode único." Pidió ver el parche de K, y Kurt Garloff replicó, "Andries, te envíe un parche hace unos meses que habilita el soporte de caracteres anchos y otro tipo de letra (además de sun12x22) que lo usa. Espero que esté en tu código base ahora, para que no se pierda cuando las cosas avanzadas de K Ratheesh sean mezcladas." Fin de la discusión.

Oleg Drokin notó que en 2.4.0-test11, habilitando hot-plugging causaría una condición de raza, si el número de interfaces de red fuera a cambiar (como al invocar ppp, en su caso). Andrew Morton publicó un largo parche, y explicó, "Yup. Esto se debe al núcleo tratando de hacer fork/exec desde un proceso medio muerto. ¿Podrías por favor probar este parche? Fue enviado a Linus para test12-pre4, pero...." Oleg replicó, "Si, funciona de esa. Pero la ruta del código y la legibilidad se volvieron horribles, desafortunadamente. :(" No hubo respuesta.

H. Peter Anvin publicó un parche (y dió un apuntador a él también), y explicó:

este es mi último intento para encontrar una forma de activar A20M# que genuinamente funcione en todas las máquinas -- incluyendo Olivettis, Aptivas IBM, notebooks bizarras, yadda yadda.

Las notebooks bizarras con código SMM descompuesto son por las que realmente me preocupo más... tal vez NO HAYA forma de darles soporte que de hecho funcione para todas las máquinas, porque no obtienes ningún tipo de retroalimentación que diga que están descompuestas.

Si has tenido problemas de A20M# con cualquier núcleo -- reciente o no -- *por favor* intenta este parche, contra 2.4.0-test12-pre5

Linus Torvalds hizo algunos comentarios técnicos, y agregó, "Por cierto, ¿sabemos actualmente de alguna máquina que realmente necesite el "and 0xfe"? Ese registro realmente me pone nervioso." A lo cual H. Peter replicó, "Buena pregunta. Toda esta cosa me pone nervioso... de hecho, ¿tal vez deberíamos realmente considerar el uso de la interrupción de BIOS INT 15h para entrar a modo protegido?" Y Alan Cox intercedió con un guiño, "De mi experiencia con autores de BIOS, sólo si Windows 98 usa la misma función con los mismos argumentos, las mismas cosas en el tope de la pila y los mismos registros de segmento cargados ;)" En otro lado, Linus continuó, "Coincido con Peter - si alguien conoce sobre programación de BIOS y cómo usar "int 15" para entrar a modo protegido, entonces esa podría ser la solución más fácil. La única razón real para que el código de configuración de linux lo haga a mano es que el código original fue escrito de esa forma - y eso fue escrito de esa forma porque nunca había usado el BIOS en mi vida antes, _y_ quería aprender el i386. Ambas de las cuales eran razones válidas en 1991. Ninguna de las cuales es probablemente una muy buena razón diez años después"

El interruptor de modo protegido en INT 15 es probablemente la función de BIOS menos probada por siempre. Yo no confiaría en ella, y basarse en ella pondría más obstáculos en los desarrolladores de Linux embebido, mucho de los cuales ni siquiera tienen un BIOS. Es 'de lo menos probado' porque no se provee forma de regresar a modo real. Esto implica que probablemente alguien la 'provó' una vez, verificó que algunas funciones simples de 32 bits se ejecutaran por unos cuantos microsegundos, y después declaró, "¡Funciona!".

Muchos juegos de chip nuevos buscan por la secuencia:

Escribe 0xd1 al puerto 0x64
Escribe 0xN1 al puerto 0x60

... Donde 'N' son cualesquiera bits y el LSB habilita la propagación A<20>

Las escrituras tienen que ser en secuencia, por lo tanto, uno debe leer 0x60 primero, OR en el bit 0. Escribe 0xD1 a 0x64, entonces escribe el nuevo valor para habilitar al puerto 0x60.

Toma entre 700 a 1500 microsegundo para un controlador de teclado real habilitar el bit de propagación A<20>. Toma sólo unos cuantos cientos de nanosegundos para la secuencia virtual, arriba, para hacer la misma cosa.

En todas las máquinas que he visto, incluyendo varias lap-tops, el puerto 'rápido' de habilitación A<20> es L/E. Esto significa que no tienes que tirar la máquina estableciendo algún bit reservado secreto. Tan sólo leer primero, OR en su bit A<20>, después escribir.

Puedes experimentar arrancando DOS (o free-DOS), y jugando usando DEBUG. Estableciendo A<20> mientras está en DOS modo real no dañará nada. Puedes hasta revisar por la envoltura más allá de FFFF:0000 desde DEBUG para ver si el bit está habilitado.

Sugiero que una secuencia "universal" es la secuencia D1/N1 mostrada arriba (esto funcionará con controladores de teclado real), no tienes que esperar que se complete el último comando mientras no tengas más de dos comandos en secuencia. Esto es porque el controlador no sabe si alguna vez lees el estado, y ejecutará el siguiente comando, si uno existe, tan rápido como escribe el estado de completo del anterior.

El siguiente paso para la secuencia "universal" si lo anterior no funciona, sería habilitar (solamente) el bit de A<20> bit (only) en el puerto 0x92.

En otro lado, Kai Germaschewski reportó falla con el parche inicial de H. Peter, diciendo, "Solo un dato: Este parche no compone el problema aquí (Sony PCG-Z600NE). Aún el reinicio espontáneo exactamente en el momento que espero recibir mi consola de vuelta de receso." Linus recibió una onda mental, y replicó:

Apuesto que se qué sucede

Quiero apostar $5 USD que ¿suspender/resumir guarda el estado A20 del teclado, pero NO guarda la información de la compuerta fast-A20?

Entonces cualquier cosa que habilita A20 con solo la compuerta rápida A20 encontrará que A20 está deshabilitado de nuevo al resumir.

Lo cual haría a Linux _realmente_ infeliz, no es necesario decirlo. Muerte instantánea en la forma de una triple falta (todo el código del núcleo Linux está en el área de 1-2MB, que sería invisible), resultando en un reinicio instantáneo.

Peter, definitivamente necesitamos hacer el teclado A20, aún si fast-A20 funciona bien.

Yup. Es un bug de BIOS, oh que impresión... (eso nunca sucede, ¿verdad?)

Podría hackearlo usando INT 15h para hacer el salto a modo protegido, así de feo como es, pero no tendré tiempo antes de mi viaje. Requeriría bastante de un poco de reestructura en setup.S, y probablemente descompondrá LOADLIN.

Justo ahora este es mi parche interino (para limpiar test11). La cosa a notar es que he decrementado el tiempo de expiración del controlador del teclado por un factor de cerca de 167, mientras hago el "retardado" un poco más grande.

Ahora, si no tienes un controlador de teclado, el retardo del arranque debe ser del orden de 1.2 segundos más o menos (llamando a empty_8042 tres veces, cada una cerca de 0.4 segundos para expirar). Lo cual es aceptable. Especialmente mientras las máquinas sin controlador de teclado que ni siquiera emulan uno son bastante raras. Y es lo suficientemente grande que si el controlador de teclano no se ha vaciado en 0.4 segundo, algo más está pésimamente mal.

El tiempo de expiración para no controlador de teclado usado era cerca de tres minutos antes. Lo cual _definitivamente_ es excesivo. La mayoría de la gente asumiría que la máquina se habría colgado.

Okay, este es otro parche A20 más (contra test12-pre6) esta vez para que la gente lo pruebe. Este parche usa el siguiente algoritmo para habilitar A20:

Intenta la llamada de BIOS. Si funciona, estamos bien.
Intenta el KBC (usando los tiempos de expiración disminuídos de Linus.)
Si el KBC no funciona, o es muy lento, activa el puerto 92.

Despuésde 3 se sienta en el mismo ciclo infinito esperando a que A20 se vuelva disponible (necesario para por ejemplo algunas notebooks Toshiba que tienen una respuesta extremadamente lenta para A20.)

Las principales diferencias entre este parche y test12-pre6:

Intenta antes que todo el BIOS. Esto reduce el riesgo del BIOS confundiéndose mientras se hace una suspensión. Esto también da menos de una excusa para cualquier arreglo no estándar -- si no implementó el KBC estándar *y* no proveyó la llamada de BIOS, tienes una pieza de hardware seriamente descompuesta.
Si el KBC responde suficientemente rápido (dentro de cerca de 10000 ciclos), nunca tocamos siquiera la compuerta A20 rápida. Esto es una diferencia de código previo, donde la compuerta A20 rápida era activada inmediatamente después del KBC, aún si el KBC respondía instantaneamente.
Tuve que mover el código de A20 un poco más temprano en setup.S para que el BIOS aún estuviera disponible.

Por favor pruébenlo y háganmelo saber tan pronto como sea posible...

Jan Niehusmann reportó corrupción de sistema de ficheros bajo los últimos núcleos de desarrollo, y durante los siguientes días publicó un parche para prevenirlo, aunque añadió, "Por favor noten que el parche circumvecina el problema más que arreglarlo. El arreglo verdadero invalidaría los mapeos, pero no sé como hacerlo." Udo A. Steinberg confirmó que el parche funcionó, y preguntó a Alexander Viro lo que él pensaba. Aquí siguió una discusión técnica muy breve, terminando con Jan preguntando por documentación y sin obtener respuesta.

Después, bajo el Subject: Trashing ext2 with hdparm, Udo reportó, "Siguiendo la discusión en otro hilo donde alguien reportó corrupción de sf cuando habilitaba DMA con hdparm, he jugado por ahí con hdparm y encontré que aún las más inofensivas operaciones de hdparm son capaces de arruinar un sistema de ficheros ext2 bastante bien." Jan replicó que estaba actualmente tratando de aislar un bug que podría estar relacionado, y Byron Stanoszek especuló, "He visto esa conducta en test-6 y superior. Pienso que tiene que ver algo con un problema en memoria compartida que es usada por el fragmento de código de 'hdparm -tT'. Creo que lidia mucho sobre los segmentos de memoria que contiene ficheros de disco en caché (los comúnmente accedidos, como /etc/mtab y /etc/utmp..etc). Cuando revisé los contenidos de esos ficheros, la memoria es obtenida del caché y aparece confusa, pero en disco aún están correctos."

Andre Hedrick objetó que el exploit de Udo no era la posible causa de corrupción, ya que era una prueba de sólo lectura. Pero Jan confirmó el exploit, y Udo también replicó a Andre, "Como otros señalaron, probablemente es algo relacionado con memora compartida, pero es definitivamente hdparm quien lo activa. No he obtenido las fuentes de hdparm aquí para ver qué es exactamente lo que está haciendo, pero hay corrupción que está sucediendo, no en disco, pero definitivamente en memoria." En este punto la discusión se disolvió sin resolver.

Reto Baettig preguntó, "¿Hay alguna forma de lograr una forma estandarizada de hacer E/S a un dispositivo de bloques que pueda manejar direcciones 64bit para el número de bloque?" Agregó que, con el esquema actual de 32-bit, "No piensas que nos meteremos en problemas de todas formas porque pronto habrá sistemas raid con unos cuantos Terrabytes de espacio para desperdiciar para mp3's ;-)" Brian Pomerantz citó un ejemplo del mundo real de este problema, diciendo, "Voy a estar poniendo juntos un sistema RAID con cerca de 1.7-5.1TB para Febrero. Esto debe ser visto como un solo dispositivo de bloque para los clientes a través de un dispositivo de bloques de red (más que probable será 16 Ciprico Rimfire 7000's distribuidos entre 4 nodos a través de un conmutador Quadrics). Así, lo que estoy viendo ahora es que no seré capaz de direccionar esa cantidad de espacio con un solo dispositivo de bloque. Para el verano de 2001 necesitaríamos ver poner juntos 10-150TB (dependiendo del presupuesto y necesidad) de espacio de disco para un cluster en producción y sería bueno si nuestro sistema de ficheros paralelo pudiera abarcar el espacio entero con una sola imagen." Stephen C. Tweedie dijo que eso estaba en la agenda para "compostura urgente" en 2.5.

David Woodhouse reportó un bug en el sistema de ficheros FAT, y Alan Cox replicó, "Te sugeriría que no corrieras el código de sistema de ficheros FAT en 2.4test* a menos que lo hagas sólo lectura o tengas los parches aplicados que componen truncate, de otra forma convertirás tu sf msdos en gelatina en este momento." Fin de la Discusión (mr).

Los chips cyrixIII por via tienen el identificador de vendedor centaur lo cual causa que la llamada identify_cpu en arch/i386/kernel/setup.c falle. Es probablemente razonable para éste tener el identificador centaur ya que via posee centaur también. Sólo reemplacé la llamada centaur_model con la cyrix_model, pero sé que estoy usando un chip cyrix.

Probablemente una prueba necesita ser agregada en la sección centaur_model para probar por el cyrixIII con disfraz.

El error es un falta de protección general.

Se disculpó en avance si esto era "sombrero viejo", pero Alan Cox replicó, "Es sombrero bastante nuevo. VIA cyrix III es una generación siguiente de IDT winchip (VIA compró las cosas winchip y las cosas Cyrix). 2.2.18 debe manejar el winchip adecuadamente." Dave Jones señaló que ls árboles estable y desarrollo ya habían tenido la prueba por algún tiempo, y preguntó a Eric, "¿Estás diciendo que las últimas versiones aún lo los reconocen?" Pero no hubo respuesta.

Carl Perry leyó en Slashdot que la API de Microsoft estaba muy mal documentada, y que no quería ver a Linux seguir el mismo camino. Preguntó si había algun proyecto en reta para documentar los subsistemas del núcleo, controladores, cuestiones de portabilidad, etc.; y se ofreció para coordinar y hospedar el esfuerzo. Jeff V. Merkey replicó, "Cualquiera que haya publicado eso en Slashdo está fumando una dosis letal o algo. La API de Windows está muy bien documentada a través de la documentación en línea de MSDN -- mejor que la mayoría del software de cualquier parte del mundo. Cualquiera que haya dicho esto estaba drogado o algo o ignorante o nunca tuvo una suscripción MSDN. Yo acostumbrara recibir 20-40 CD's al mes de MS en una Suscripción Universal, con documentación enorme.." Alan Cox también replicó a Carl:

Para las cosas del núcloe hay un proyecto para poner la documentación acerca de las funciones y lo que hacen insertado en el núcleo. Tiene progreso lento. Tratar de hace cualquier cosa formal y estructurada no va a ser productivo hasta que la documentación sea mucho mucho más completa

Para llamadas al sistema Andries Brouwer mantiene una colección de páginas de manual (y escribe muchas de ellas). Él recibe contribuciones.

Daniel Phillips dió un vínculo a la Referencia Cruzada Linux, y recordó, "Yo se exactamente cómo se siente cuando por primera vez entras en las interfaces internas del núcleo - para mí fue hace escasamente un año. Quise en ese momento tratar y componer todos los problemas de documentación mientras seguí, pero rápidamente se convirtío en una elección entre hacer desarrollo útil y hacer documentación útil. Adivina cuá escogí. Sinceramente espero que otros harán la elección opuesta, y que el mundo de hackeo de linux será un mejor lugar." También dió una liga a las páginas de Información de Linux de Andries Brouwer y a la página de vínculos de Kernelnewbies. Añadió, "Tigran Aivazian ha estado preparando 'Interiores del Núcleo Linux' el cual es *altamente recomendable* y 100% libre. ¿Por qué no te juntas con él, y Gary Lawrence Murphy (ve su lata wiki mensual del núcleo)?" y Tigran Aivazian replicó, con respecto a "Interiores del Núcleo Linux:

en caso que sea curioso sobre dónde encontrarlo:

http://www.moses.uklinux.net/patches/lki.html

(o .sgml para la fuente maestra).

De forma interesante, el principal problema con LKI resultó ser _no_ el asunto de mantenerlo al día sino llenar las partes faltantes, más notablemente el caché de memoria temporal y el caché de páginas. Por ahora en este momento más o menos entiendo el caché de memoria temporal de Linux (solamente después de una comparación diligente con UW7, AIX, OSR5 y varias otras implementaciones comerciales de UNIX cuyo código fuente está disponible) pero aún no el caché de páginas (aún después de leer todo lo que pude encontrar acerca de eso, incluyendo el libro reciente Entendiendo el Núcleo Linux por Bovet que acabo de terminar de leer). P.e. no es siquiera obvio para mí que las cosas se pongan peor si alguien desecha toda la lógica de readahead del caché de páginas.

Así, si alguien quiere escribir un capítulo sobre caché de páginas en Linux y contribuir al libro INL (y así convertirse en un co-autor :) por favor siéntase libre -- será una prueba de que alguien en el mundo lo entiende en este momento -- por el momento eso lo dudo mucho... Tómenlo como un reto :)

Pavel Machek notó, algo para su desaliento, que era posible borrar un archivo de intercambio que estuviera en uso. Tratando de ejecutar 'swapoff', en cambio, reportaría el fichero como no existente. Creando el fichero de nuevo e intentando 'swapoff', daría un error. Sin correr 'swapoff', no pudo reiniciar de forma segura el sistema. Pidió ayuda.

Rik van Riel sugirió no borrar los ficheros en primer lugar, y agregó que reiniciar era la única solución. Pavel argumentó que el error era muy fácil de hacer, y que debía ser prevenido si era posible, o por lo menos debía existir una forma de recuperarse. Agregó que reiniciar causaría problemas, ya que el sistema de ficheros aún estaba ocupado.

No apareció una solución para Pavel durante la discusión, pero Peter Samuelson sugirió, "agregar código a /sbin/swapon y /sbin/swapoff para establecer y limpiar el bit de inmutabilidad. Seguro que sólo funciona en ext2 pero ¿qué tan lejos quieres llevar esta cosa?" Alguien más sugirió agregar entradas en /proc para cada archivo de intercambio, así root podría correr 'swapoff' aún si fueran borrados. A David Feuer le gustó la idea, y el hilo de la discusion terminó.


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

1.	24 Nov 2000 - 5 Dec 2000	(34 posts)	Discusión Sobre Licencia
2.	28 Nov 2000 - 4 Dec 2000	(56 posts)	Cazando Varios Bugs De Corrupción Del Sistema De Ficheros: La Saga Continúa
3.	30 Nov 2000 - 7 Dec 2000	(9 posts)	Controlador De Puerto Serial En Espacio De Usuario
4.	1 Dec 2000 - 4 Dec 2000	(8 posts)	Problemas Con La Limpieza De Código De Sonido Propuesta En Las Series Estables
5.	1 Dec 2000 - 6 Dec 2000	(12 posts)	Pánico de Núcleo En La Autodetección De SoftwareRAID Autodection En Núcleos Recientes De Desarrollo
6.	3 Dec 2000 - 9 Dec 2000	(16 posts)	Falsa Detección Del Ratón PS/2 En Núcleos Estables Recientes
7.	3 Dec 2000 - 4 Dec 2000	(3 posts)	Soporte De Lenguaje Local
8.	4 Dec 2000	(3 posts)	Condición De Raza Con Hot-Plugging Y El Número de Interfaces De Red
9.	5 Dec 2000 - 8 Dec 2000	(21 posts)	Negociando La Compuerta De Dirección A20
10.	5 Dec 2000 - 7 Dec 2000	(6 posts)	Corrupción De Sistemas De Ficheros En Núcleos De Desarrollo
11.	6 Dec 2000 - 7 Dec 2000	(5 posts)	Estado Del Soporte A Sistemas De Ficheros Grandes
12.	6 Dec 2000 - 7 Dec 2000	(2 posts)	FATFS Aún No Está Listo En Series De Desarrollo
13.	7 Dec 2000	(3 posts)	Problema IDentificando Chips Cyrix III De Via
14.	7 Dec 2000 - 8 Dec 2000	(6 posts)	Documentación del Núcleo
15.	9 Dec 2000 - 10 Dec 2000	(7 posts)	Corriendo 'swapoff' En Archivo De Intercambio Borrado

Tráfico del Núcleo #98 For 18 Dec 2000

By Zack Brown

Translated By: Cristian Othón Martínez Vera