|
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 |
linux-kernel FAQ | subscribe to linux-kernel | linux-kernel Archives | kernelnotes.org | LxR Kernel Source Browser | All Kernels | Kernel Ports | Kernel Docs | Gary's Encyclopedia: Linux Kernel | #kernelnewbies
Table Of Contents
| 1. | 21 Dec 2000 - 26 Dec 2000 | (14 posts) | Recommended GCC Compiler Version |
| 2. | 25 Dec 2000 - 26 Dec 2000 | (4 posts) | Some BIOSes Favoring Microsoft |
| 3. | 29 Dec 2000 | (3 posts) | PowerPC Tree Out Of Date |
| 4. | 30 Dec 2000 | (3 posts) | Some Crossed Wires With Patch Submission |
| 5. | 30 Dec 2000 | (4 posts) | Status Of PowerPC Port In The Official Tree |
| 6. | 30 Dec 2000 - 31 Dec 2000 | (2 posts) | POSIX Message Queues |
Introduction
Leider, leider dieses Mal noch nichts über die 2.4 Release; dieses Mal ist auf die Weihnachts-, Neujahrszeit beschränkt, es gab also nicht besonders viele Threads. Nächste Woche dann einiges über den 2.4stable Kernel!
Mailing List Stats For This Week
We looked at 546 posts in 2549K.
There were 230 different contributors. 105 posted more than once. 0 posted last week too.
The top posters of the week were:
1. Recommended GCC Compiler Version
21 Dec 2000 - 26 Dec 2000 (14 posts) Archive Link: "recommended gcc compiler version"
People: Barry K. Nathan, Linus Torvalds, Alan Cox
Robert B. Easter wollte wissen, welche Compiler Version für 2.2.18 und 2.4-test Kernel empfohlen wird. Barry K. Nathan empfahl für 2.2.18, " gcc 2.7.2.3 ist am sichersten, doch sollte egcs 1.1.2 auch für kritischere Sachen in Ordnung sein. gcc 2.95.2 läuft bei sehr vielen Leute, auch wenn er nicht der sicherste ist. Für den 2.4er Kernel ist egcs 1.1.2 die sicherste Wahl, doch sollte auch gcc 2.95.2 gehen. 2.7.2.3 läuft eher nicht auf 2.4, also scheint 2.4 Präprozessor-Checks eingebaut zu haben, die mit 2.7.2.3 die Kompilierung fehlschlagen lassen." Er sagte auch, dass in Documentation/Changes die Compiler-Versionen für jede Release aufgelistet sind. Linus Torvalds kam dazu:
Trotz meiner öffentlichen Kommentare über die schlechte Idee nur mies getestete Compiler in einer Haupt-Release mitzuliefern denke ich, dass es wunderbar wäre, wenn es viele Leute gibt die sich auf die Resultate des neuen 2.96 gcc vorbereiten.
Er wurde noch nicht besonders weitläufig getestet, aber wenn man sich ein bisschen damit auskennt (oder lernen möchte) erzeugt gcc-2.96 _wesentlich_ besseren Maschinencode und wenn ihn keiner wirklich testen will, werden alle Bugs (ob sie in den Kernel-Quellen selbst sind oder von einem smarteren Compiler im Kernel angestossen wurden) nicht gefunden.
Also probiert den bitte aus.
Es wäre echt gut, wenn ich hier - sogar mit CVS Snapshots - einige Erfahrungen hören würde. Ich kann es nur nicht haben, wenn diese in Distributionen auftauchen ;)
Hierzu berichtete Matthew Vanecek, dass der aktuellste gcc 2.96 mit den Updates von Red Hat für seinen Kernel einwandfrei lief.
Alan Cox gab seine empfohlenen Compiler bekannt und sagte, " Red Hat's 2.96 scheint korrekte Kernel zu erzeugen, doch kann man hier keine Sympathie mit Bugberichten erwarten, wenn einer auftauchen sollte." Und Linus fuhr fort:
Nun, nun, ich möchte vor allem Berichte über die speziell aktualisierten Compiler hören. Ich habe tatsächlich keinen einzigen Bericht über Probleme mit den alten 2.96 gehört; ich sah nur zu viele User-Land Probleme mit diesem Compiler, die mich daran zögern lassen würden, diesen für den Kernel einzusetzen.
Ausser meiner Abneigung gegen ausgelieferte Snapshot-Compiler würde ich es lieber haben, dass RedHat ihre "kgcc" Geschichte fallenlässt; und um das zu tun, müssen Leute diesen neuen Compiler testen.
Ich möchte dies den Leuten nur sagen, damit ich Bug-Berichte und Compiler-Versionen in Verbindnug bringen kann. Sicher ist sicher. Es kann wichtig werden (und nicht nur wegen Compiler-Bugs, sondern auch wegen echter Kernel-Bugs, die nur durch puren Zufall durch dem Compiler versteckt sind). Und es hilft _SEHR_ wenn man einen alternativen Compiler hat, um so etwas zu vergleichen.
2. Some BIOSes Favoring Microsoft
25 Dec 2000 - 26 Dec 2000 (4 posts) Archive Link: "BIOS problem, pro Microsoft, anti other OS"
People: Marvin Stodolsky, David Riley
Marvin Stodolsky berichtete:
Einige PC BIOS Chips werden nun mit einer Default Microsoft Einstellung ausgeliefert, welche sie auf Kriegsfuss mit der Funktionalität anderer Betriebssysteme bringt. Wenn speziell unter Linux ein PCI Winmodem NICHT mit der Win98 BIOS Einstellung lief, lief es einwandfrei mit der Einstellung "Other OS". Vielleicht sind hier auch andere PCI-Geräte unter Linux ähnlich belastet.
Dies indiziert die Notwendigkeit einer Linux Installationssoftware die mit einem Tool ausgeliefert wird, welches das BIOS prüft und ein eventuelles "Linux feindlich" berichtet. Heutzutage werden die meisten PC-Systeme mit WinModems verkauft. Die feindlichen (und voreingestellen) BIOS Einstellungen werden Newbies dann daran hinden, online gehen zu können.
David Riley antwortete, "Ich glaube nicht, dass man das als "Linux feindlich" klassifizieren kann, eher als "Linux ignorant". In den meisten ordentlichen BIOS Setups heisst die "Windows"-Option "PnP OS". Die Ersteller deines BIOSes waren einfach der Annahme, dass Windows das einzige OS ist, dass PnP korrekt bearbeitet (obwohl das bis vor kurzem alles andere als der Wahrheit entsprach). Jedenfalls sollte ein neuerer Kernel (wie 2.4.0-test12) das Problem lösen, da es die PnP-Sachen korrekt erkennt."
3. PowerPC Tree Out Of Date
29 Dec 2000 (3 posts) Archive Link: "PowerPC branch out of date"
Tom Gall berichtete:
Ich arbeite für den PowerPC Teil des Kernels. Ich konnte seit einiger Zeit feststellen, dass das was es auf kernel.org gibt und dem, was von Leuten wie uns, die an dem kleinen PowerPC Tree arbeiten, weniger und weniger miteinander synchronisiert ist.
Wie es dazu kam usw. ist jetzt nicht wichtig. Erstens wie soll das gelöst werden und zweitens, wie verindert man dass es wieder passiert.
Momentan ist der diff zwischen test13-preX und des Master fsmlabs.com PPC Trees ca. 450k gross. Wäre es richtig, diesen Patch in die test13-preX Release einzubringen?
Es würde mir WIRKLICH gefallen, wenn das möglich ist. Ich habe ein ganzes Boot voll von RS/6000 (die pSeries) Hardware, die ich nutzen könnte, wenn dieser Patch drin wäre. Es ist echt eine Schande den Leuten erklären zu müssen, dass kernel.org der Ort sein *SOLLTE*, einen guten Kernel zu bekommen, aber da diese Dinge nicht synchronisiert sind, muss ich sie auf eine andere Stelle verweisen.
Rik van Riel empfahl Patches an Linus Torvalds oder Alan Cox zu schicken, doch Tom meinte, " test13-pre5-acXX ist mit den wichtigen Sachen ohnehin up-to-date. Ob es in den Tree von Linus kommt ist der wichtige und unbekannte Teil."
4. Some Crossed Wires With Patch Submission
30 Dec 2000 (3 posts) Archive Link: "test13-pre6 compile error..network.o"
People: Alan Cox
Frank Davis erhielt während der Kopilierung von 2.4.0test13-pre6 einige "undefined references" in network.o. Andrew Morton postete einen Patch, der das behebt und Alan Cox erklärte, " Meine Schuld. Ich habe Linus ein paar Sachen zu viel gesandt, um die Netzwerksachen zu säubern. Von den Haupt-Netzwerk Fixes fehlen noch einige für Linus' Tree. "
5. Status Of PowerPC Port In The Official Tree
30 Dec 2000 (4 posts) Archive Link: "Linux 2.4test-ac merge status"
Alan Cox gab 2.4.0test13pre7-ac1 bekannt und erklärte, " Das ist, um Leuten eine Idee zu geben, was für -ac Sachen bereits Linus gegeben wurden, was noch Arbeit benötigt, was in den Bit-Kontainer für schlechte Idee geworfen wurde, usw." Tom Rini fragte, ob der PowerPC Port in den Bit-Kontainer geworfen wurde und Alan antwortete, " Es kann sein, dass der PowerPC Port in 2.4.0ac1 und 2.4.2 Linus oder sonstwo ist/kommt. Ich glaube nicht, dass das ein grosses Problem ist. Ich muss an die Spitze von 2.2.19pre4 und den Rest des Linus Sync kommen; dann werde ich Teile aus dem -ac schaffen und schauen einen schönen, sauberen -ac Tree zu bekommen. Wenn jemand nicht-x86 Sachen mit dem gesagten synchronisieren will, nur zu." Tom antwortete, " Oh gut. Ich schätze unser Problem ist es, dass wir es nicht schaffen Linus auf die kleinen Änderungen aufmerksam zu machen und er ausserdem grosse Patches hasst."
6. POSIX Message Queues
30 Dec 2000 - 31 Dec 2000 (2 posts) Archive Link: "Posix MessageQ's"
People: RAJESH BALAN, Gabi Davar
Rajesh Balan fragte, "Unterstützt Linux POSIX Message Queues? Ich beziehe mich auf Richard Stvens V2 für IPC.. Im Buch steht, dass <mqueue.h> includiert wird, doch ich konnte nichts finden. Ich benutze Linux 2.2" Gabi Davar antwortete, " POSIX Message Queues werden in der glibc v2.2 noch nicht unterstützt (POSIX Semaphore sind teilweise implementiert). Wenn irgendwann glibc diese unterstützen wird, kann man deren Existenz via sysctl() und an den relevanten defines erkennen. So weit ich weiss, implementiert Linux nur SysV Message- Queues. Solaris und True64 implementieren sie trotzdem."
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. |