|
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 Linux LxR | Todos los Núcleos | Núcleos Transportados | Documentos del Núcleo | Enciclopedia de Gary: Núcleo Linux | #kernelnewbies
Table Of Contents
| 1. | 30 Jun 2001 - 5 Jul 2001 | (8 posts) | Soporte Para Bloques De 64-Bit |
| 2. | 4 Jul 2001 | (1 post) | Subject: "State of CML2" |
| 3. | 4 Jul 2001 - 6 Jul 2001 | (5 posts) | Identificando Mezclas De Núcleos -ac Al Árbol de Linus |
| 4. | 4 Jul 2001 - 5 Jul 2001 | (4 posts) | Problemas de Archivo De La Lista De Correo |
| 5. | 6 Jul 2001 - 7 Jul 2001 | (4 posts) | Estado De ext3 |
| 6. | 9 Jul 2001 - 10 Jul 2001 | (28 posts) | Límites De Memoria Por Proceso |
| 7. | 10 Jul 2001 - 11 Jul 2001 | (4 posts) | Resucitando El Transporte A sparc32 |
| 8. | 10 Jul 2001 - 11 Jul 2001 | (4 posts) | Choque En Compilación De ESS137x |
Introduction
Quiero dar la bienvenida a John Guthrie. Su primera contribución puede ser pequeña, pero era un hilo que yo había ignorado inadvertidamente, así que sólo es por su buen ojo que TN lo tiene esta semana. Adam también está de regreso esta semana, con un muy buen trabajo.
Mailing List Stats For This Week
We looked at 908 posts in 3534K.
There were 370 different contributors. 156 posted more than once. 130 posted last week too.
The top posters of the week were:
1. Soporte Para Bloques De 64-Bit
30 Jun 2001 - 5 Jul 2001 (8 posts) Archive Link: "[RFC][PATCH] first cut 64 bit block support"
Summary By Zack Brown
People: Ben LaHaise
Ben LaHaise publicó un parche y anunció, "A continuación está el primer intento de hacer el límite del tamaño de bloque configurable a 64 bits en x86, así como siempre 64 bits en máquinas 64 bit. La auditoría aún no está completa, pero un buen bloque de eso está hecho." [..] "Los siguientes deben ser limpios a 64 bit ahora: nbd, loop, raid0, raid1, raid5." Dió vínculos a dos páginas en http://people.redhat.com/bcrl/lb/ y http://www.kvack.org/~blah/lb/. Agregó, "Partes feas: Tengo que agregar libgcc.a para satisfacer la necesidad de la división de 64 bit. Si, apesta, pero RAID necesita algo más de masaje antes de que pueda quitar la división 64 bit completamente. Esto será compuesto." Chris Wedgwood propuso algunos cambios a libgcc.a para que sea menos feo, y Ben replicó, "Me estoy deshaciendo de la necesidad de libgcc completamente. Esto es lo que significa "Esto será compuesto". Si quieres agilizar el proceso, envía un parche. Hasta entonces, esto es Suficientemente Bueno para propósitos de prueba."
En otro lugar, Ragnar Kjarstad estaba muy feliz acerca del trabajo de Ben, preguntando si LVM era también limpio a 64-bit. Ben replicó crípticamente, "Errr, me refrenaré de hablar acerca de LVM." Ragnar pidió alguna aclaración, y Ben explicó:
Componer LVM no está en el radar de mis prioridades. El código está necesitado urgentemente de una reescritura y viola varios de los principios básicos de planeación que debería seguir cualquier buen código en el nivel de bloques. Por mencionar, debe tener 1) planeado el dar soporte a desplazamientos de 64 bit, 2) nunca usar multiplicación, división o módulo en números de bloque, y 3) no alojar estructuras de memoria que están indizadas por números de bloque. LVM falló en los tres de estos -- y esto es sólo lo que noté en una vista rápida de 5 minutos a través del código. Lo siento, pero LVM es obsoleto por diseño. Continuará trabajando en dispositivos de bloque de 32 bit, pero si tratas de usarlo más allá de eso, fallará. Dicho esto, tendremos que asegurarnos que estas fallas sean con gracia y ocurran previamente a que el usuario tenga la oportunidad de perder cualquier dato.
Ahora, agradezcamos que hay alternativas como ELVM, que están trabajando en obtener los detalles bien de las lecciones aprendidas. Dado eso, pienso que estará en buena forma durante el ciclo 2.5.
Fin Del Hilo De Discusión (mr).
2. Subject: "State of CML2"
4 Jul 2001 (1 post) Archive Link: "State of CML2"
Summary By John Guthrie
People: Eric S. Raymond
Eric S. Raymond anunció:
El núcleo CML2 está en buena forma. No ha habido ningún error serio desde mediados de Abril. La última versión (1.6.9) se resincroniza con 2.4.6 y ac24 y agrega mejor revisión de tipos en tiempo de compilación en expresiones (gracias a Daniel Junglas por sacarme de la oscuridad en esto).
Hay un par de rarezas menores de Tkinter que permanecen en la interfaz xconfig, pero no parecen mostrarse en la operación normal con el fichero de reglas del núcleo Linux. Están completamente descritas en el fichero TODO de la distribución.
No hay quejas de velocidad de los probadores beta últimamente; la saga de afinación en Mayo parece haber funcionado. Las peticiones que estoy recibiendo son muchas más por menores ajustes de UI (Interfaz de Usuario).
CML2 tiene otra victoria de diseño. Las gentes de Webmachines ahora lo utilizan para configurar la distribución Linux que ponen en las ROMs flash de sus dispositivos de red. Una edición ligeramente editada del archivo de reglas de Webmachines está disponible en el sitio del proyecto CML2 como un ejemplo.
Los muros del calabozo en CML2 aventura ahora muestran ocasionalmente grafitti entretenido. Localice todas las bromas internas y recolecte un valioso no-premio.
CML2 está listo.
3. Identificando Mezclas De Núcleos -ac Al Árbol de Linus
4 Jul 2001 - 6 Jul 2001 (5 posts) Archive Link: "Linus vs. AC kernels"
Summary By Zack Brown
People: Alan Cox
John Weber preguntó cómo encontrar qué partes de los núcleos -ac han sido mezclados en el árbol de Linus Torvalds. Tim Waugh sugirió usar diff. En un punto Alan Cox dijo, "La mezcla de los árboles -ac y Linus no es ni remotamente en el orden de las versiones -ac, Eso lo hace mucho más complejo de clasificar."
4. Problemas de Archivo De La Lista De Correo
4 Jul 2001 - 5 Jul 2001 (4 posts) Archive Link: "Mail list archives down"
Summary By Zack Brown
People: David Balazic, Erik Mouw
David Balazic notó:
Noté que 4 de 5 archivos web de LKML enumerados en el FAQ están fuera el día de hoy.
Están enumerados en el FAQ de LKML en http://www.tux.org/lkml/ :
¿ Teorías de conspiración ?
Erik Mouw agregó un vínculo a http://www.geocrawler.com/lists/3/Linux/35/0/, diciendo, "Aquí hay otro que se actualiza en tiempo real pero no da soporte al modo de hilos de discusión." Havard Kvalen dio una liga a uno que parece que funciona. Samuli Kaski también apuntó a un archivo simple.
(ed. [Zack Brown] El mejor archivo que he encontrado es el primer vínculo en la lista de David. Si alguien encuentra algo mejor, por favor hágamelo saber.)
5. Estado De ext3
6 Jul 2001 - 7 Jul 2001 (4 posts) Archive Link: "ext3-2.4-0.9.0"
Summary By Zack Brown
People: Andrew Morton
Andrew Morton anunció:
Una actualización para el sistema de ficheros de jornada ext3 para los núcleos 2.4 está disponible en
http://www.uow.edu.au/~andrewm/linux/ext3/
Los parches son en contra de 2.4.6-ac1 y 2.4.6
Cambios desde 0.0.8 incluyen:
El último cambio es problablemente el más significativo - previene posibles caídas y corrupción de sf bajo cargas de trabajo extremas.
6. Límites De Memoria Por Proceso
9 Jul 2001 - 10 Jul 2001 (28 posts) Archive Link: "What is the truth about Linux 2.4's RAM limitations?"
Summary By Adam Buchbinder
People: Adam Shand, Andi Kleen, Brian Gerst
Adam Shand explicó, "Donde empecé a trabajar corremos grandes procesos para simulaciones" [...] "Actualmente usamos Solaris debido a limitaciones pasadas en la cantidad de RAM que un solo proceso puede direccionar bajo Linux." Publicó dos preguntas:
Prosiguió en publicar los resultados de su investigación sobre la materia, diciendo que no existía una fuente definitiva:
Agregó que toda la información que recibiera acerca de esto iría a su sitio web.
Andi Kleen replicó que la constante __PAGE_OFFSET podía elevar el límite de RAM por proceso, y que arch/i386/vmlinux.lds tenía que ser editado (Él no dijo cómo). También especuló, "La razón por la cual tu simulación se detuvo a 2.3GB se debe a que el alojamiento malloc le pegó a las bibliotecas compartidas (revisa con /proc/<pid>/maps). Hay formas para decirle a malloc que use mmap más agresivamente (ve la documentación de malloc en info libc) o moviendo las bibliotecas compartidas hacia arriba cambiando una constante del núcleo llamada TASK_UNMAPPED_BASE."
En otro lado, Rik van Riel dijo que el límite por proceso era 3GB, y era un límite de hardware. Brian Gerst también explicó que las extensiones PAE permitían el uso de "64GB de memoria FÍSICA. El procesador aún está limitado a 4GB de memoria VIRTUAL por tabla de página (por proceso) que debe ser compartido entre el espacio de usuario y el espacio del núcleo. Linux usa una separación 3:1."
Hubo algunas sugerencias para expandir la porción de espacio de usuario del espacio de 4GB, pero el concenso fue que podría llevar a inestabilidad y golpes al rendimiento inaceptales. En un punto Jesse Pollard preguntó por una referencia completa sobre las capacidades de direccionamiento de Intel, y Jonathan Lundell dio un vínculo a los manuales de referencia del Pentium III de Intel.
7. Resucitando El Transporte A sparc32
10 Jul 2001 - 11 Jul 2001 (4 posts) Archive Link: "Kernel 2.4.6 does not compile on Sparc"
Summary By Adam Buchbinder
People: Fabrizio Gennari, Doug McNaught, Peter Zaitcev, Alex Buell
Fabrizio Gennari reportó problemas compilando 2.4.6 en un Sparc. "Parece que pgalloc.h define como macros algunos identificadores que están definidos en otro lado como funciones." Dijo que esto era el mismo problema que Alex Buell había reportado a la lista el 9 de Mayo.
Doug McNaught replicó, "Actualmente, 2.4.X no compila o corre en Sparc32 debido a la falta de un mantenedor para esa plataforma." Peter Zaitcev publicó un vínculo a un largo parche suyo que "compila, pero no corre muy bien. Puede ser un buen inicio si quieren componer sparc(32)."
Alex Buell dijo que vería el parche tan pronto como regresara de vacaciones. Durante este tiempo, pidió, "si alguien en UK está dispuesto a donar una SparcStation 20 con SM61s dual (o mejor aún, SM71s) con un framebuffer 24bit, puedo asegurar que SMP funcione en sun4m." No hubo respuesta.
8. Choque En Compilación De ESS137x
10 Jul 2001 - 11 Jul 2001 (4 posts) Archive Link: "es1370/1371 compilation clash"
Summary By Adam Buchbinder
People: Martin A. Brooks
Martin A. Brooks reportó un error mientras trataba de compilar ambos controladores (de sonido) es1370 y es1371 bajo 2.4.6-ac2:
es1371.o(.text+0x587c): multiple definition of `gameport_register_port'
es1370.o(.text+0x5670): first defined here
Alexander Griesser publicó un parche para prevenir que los símbolos fueran definidos dos veces, Martin reportó éxito, y el hilo de discusión terminó aquí.
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. |