Kernel Traffic #121 For 11 Jun 2001

Dies sollte wirklich Linus und/oder Alan selbst beantworten, aus meiner eigenen Erfahrung aber denke ich, dass es so läuft:

Alan und Linus stimmen nicht immer überein, was in den Kernel soll; selbst wenn das der Fall ist, bleibt immer noch die Frage wann das sein soll. Alan könnte vielleicht denken, dass gewisse Patches eingebunden werden sollen, während Linus dem ganzen noch ein wenig Zeit geben will; vielleicht denkt er auch, dass der Versuch in die falsche Richtung führt und daher abgelehnt werden soll. Also fügt in Alan in seinen Tree ein und Linus nicht (natürlich läuft das auch manchmal umgekehrt). Dann geschieht es zeitweise, dass sich die Änderung besser als erwartet herausstellt (besonders nach einigen Bug-Reports) und der- jenige, der den Patch anfänglich verweigert hat, nimmt ihn später mit in seinen Tree auf. Ausserdem gehen Linus und Alan nie so weit auseinander, da immer wieder ein Sync der Patches erfolgt.

Auch ich hatte Schwierigkeiten, mit jeweils beiden Kernel Trees zurecht- zukommen. Dennoch finde ich jetzt, das es gut so ist. Es erlaubt verschiedene Vorlieben und die dazu sinnvolle Version zu beziehen. Wenn die zwei Kernel eine reales Problem auf verschiede Arten lösen, sieht man welcher Versuch der bessere war. Auch schauen Alan und Linus genau darauf, dass die beiden Kernels nicht zu weit auseinanderdriften. Ich bin der Meinung, dass dieses Zusammenspiel (ist konkurrierend hier zu hart?) zu einem qualitativ besseren Kernel geführt hat.

• New mount option show_sys_files=<bool> to show all system files as normal files.
• Support for files and in general any attributes up to the full 2TiB size supported by the NTFS filesystem. Note we only support up to 32-bits worth of inodes/clusters at this point.
• Support for more than 128kiB sized runlists (using vmalloc_32() instead of kmalloc()).
• Fixed races in allocation of clusters and mft records.
• Fixed major bugs in attribute handling / searching / collation.
• Fixed major bugs in compressing a run list into a mapping pairs array.
• Fixed major bugs in inode allocation. Especially file create and mkdir.
• Fixed memory leaks.
• Fixed major bug in inode layout assignment of sequence numbers.
• Lots of other bug fixes I can't think of right now...
• Fixed NULL bug found by the Stanford checker in ntfs_dupuni2map().
• Convert large stack variable to dynamically allocated one in ntfs_get_free_cluster_count() (found by Stanford checker).
• New versioning scheme as I was too confused by the date based one... (versions prior to this are internal only, never been released to public, so you haven't missed the numbers before 1.1.15).

• Der Treiber sollte nicht mit Schreibzugriff genutzt werden, sonst kann das Dateisystem korrupt sein. Falls es genutzt werden soll, sollten die Linux-NTFS Tools verwendet werden und nach dem Unmounten einer Partition das ntfsfix Utility.
• "ls" zeigt im Gegensatz zu "ls -l" manchmal nicht den letzten Verzeichnisseintrag an (?!?)
• Die show_sys_files Mountoption hilft bei vielen Problemen. (Es werden sowohl Dateien mit langen und kurzen Namen sowohl Systemdateien angezeigt.)
• Spezielle Zeichen werden nicht korrekt verarbeitet. Beispielsweise kann eine Datei, die im Namen einen Apostroph enthält nicht geöffnet werden.
• Es gibt noch keine Unterstützung für das Schreiben von Extension Records.

Das Hauptproblem mit VIA ist nicht, dass sie Hardware Bugs haben. Jeder hat Bugs. Mit einem Intel Problem kann ich zu developer.intel.com gehen und erhalte auch normalerweise eine gute Antwort und oft gleich einen Workaround. Das finde ich klasse. Das Problem ist nicht der Bug selbst, sondern dass es absolut keine Infos dazu gibt.

Wenn VIA eine öffentliche Errate hätte, wie 'Prefetch Bursts könnte Probleme verursachen, wenn nicht Bit 3 von blah gesetzt ist', hätte wir die Möglichkeit, Leistungseinflüsse zu analysieren und sensible Entscheidungen zu treffen, um zuverlässigen Code zu erstellen.

Doch auch Intel ist nicht perfekt. Wir haben ein Haufen Laptops die crashen, wenn speedstep einen Trap auslöst, den wir nicht behandeln können. Es gibt ein APIC Problem, das eine Menge Arbeit gekostet hat, weil sie nicht helfen wollten.

Wenn die Hersteller dazuhelfen, wird alles viel einfacher. AMD USB war ein Errata Problem. Als sie dann den AMD USB Fix gestellt haben, gab es kein Problem mehr.

Scheint so, dass der Bug in den DMA spezifischen Teil des VIA Chipsatzes und/oder im Linux DMA-IDE VIA Treiber liegt. Den Hänger bin ich jetzt los, indem ich einfach den kompletten IDE-DMA nicht mit einkompiliert habe. Soweit ich das sagen kann, verhält sich das System jetzt stabil.

Ich habe das diie letzten Tage SEHR intensiv getestet und konnte ein Aufhängen des Systems nicht mehr provozieren. 12 Stunden lang ließ ich konkurrierende Prozesse Gigas von Daten herumkopieren, ließ CPU-intensive Krypto-Sachen laufen, usw. Für Debugging-Zwecke habe ich auch 2.2.19 mit IDE-DMA probiert. Das System crashte. Also scheint hier wirklich DMA das Problem sein.

In BSD gibt select() an, dass - wenn ein Timeout erscheint - die als Parameter übergebenen Bits nicht geändert werden. Linux, das laut Manpage BSD-Compilance haben soll (aber überhaupt nichts aussagt, was mit den Bits geschieht), setzt die Bitmaske auf Nullen, wenn eine Timeout auftritt. Ich habe einen Testfall geschrieben und auf beiden Systeme getestet; BSD verhält sich, wie angegeben, Linux nicht BSD-gerecht.

Sollen jetzt die Manpages geändert werden, dass sie die Wahrheit widergibt oder soll select() geändert werden, um wie in BSD zu funktionieren?

Vor einigen Wochen versprach ich Jeff Garzik, eine kleine procfs-Dokumentation zu schreiben. Diese ist im SGML DocBook Format und führt aus, wie man das procfs innerhalb des Kernels benutzt.

Ich suche noch nach einer ordentlichen Weise, die Beispielquellen automatisch in die SGML-Datei einzufügen, der Patch mit dem gleichen Inhalt in zwei verschiedene Dateien ist ein klein wenig nervig.

Der Patch ist für Linux-2.4.5, aber sollte auch mit 2.4.5-ac* sauber laufen.

Mit gutem Gefühl gebe ich das Configure.help Masterfile bekannt, dass jetzt mit dem 2.4.5 Stand komplett ist. Jede einzelne der insgesamt 2699 Konfigurationssymbole aus den C-Quelldateien und Makefiles von 2.4.5 haben jetzt einen Eintrag in Configure.help.

Das heisst natrülich nicht, dass das pflegen von Configure.help jetzt ein Ende hat; neue Symbole werden in Zukunft hinzukommen und andere wegfallen (es existieren eine Handvoll in ac5, alle sind jetzt dokumentiert) und existierende Symbole könnten umgeschrieben und erweitert werden. Aber wir haben einen Milestone erreicht -- die Datenhaltung wird nur noch eine leichte Übung sein.

Danke an alle, die dazu beigetragen haben, mehr als 550 Einträge zusammen- zutragen. Das Ergebnis ist hier:

http://www.tuxedo.org/~esr/cml2/Configure.help.gz

Obwohl es auf der CML2 Projekt-Homepage liegt, kann es auch in Beug auf Linus und Alan's mit CML1 genutzt werden.

Jetzt habe ich zwei bitten an Linus und Alan:

1. Bitte nehmt diese Arbeit jetzt auf. Es ist wirklich eine entscheidende Verbesserung in euren Trees, es einzubauen kann auch nichts kaputtmachen. Ausserdem spart man sich dann zukünftige, unnötige Patch Unverträglichkeiten.
2. Bitte stellt einen Standard auf, dass Patches, die neue Konfigurations- symbole einfüugen und nicht einen erklärenden Text in die Configure.help eintragen, abgelehnt werden -- und bitte *veröffentlicht* es auch, dass ihr das tun werdet. Wir können jetzt unseren Standard erhöhen und damit wir einen gut-dokumentierten Kernel und ein ordentliches Konfigurationssystem haben, schlage ich vor, das jetzt durchzuziehen.

Ich stimme nicht überein mit dem dass 2.4.xx schlecht oder beta sein soll.

Wir als Administratoren haben die Verantwortung frühe Kernels zu testen und gute Bug-Reports zu schicken, damit Entwickler ihre Bugs beheben können. Das ist unser Weg, um zur Gemeinde etwas beizutragen.

Dennoch ist es wirklich risikoreic diese Kernel auf Haupt 24x7 Produktions- servern einzusetzen.

Dies ist gültig für 1.2.x, 2.0.x (meiner Meinung nach die beste Linux Kernel Serie) 2.2.x und 2.4.x und wird auch bei 2.6.x nicht anders sein.

Angenommen wir würden wissen, dass der Support von Open Source Entwicklung besser als der von kommerziellen Supportverträgen ist, wüsste ich keinen Grund sich über die Werke all dieser wunderbaren Hacker zu beschweren.

Die Aufzeichnungen von Linus über 2.4 sind klar in der Hinsicht, dass man mindestens doppelt soviel Swap wie RAM braucht.

Marcelo arbeitet daran, damit sich das ändert, momentan versuchst du aber etwas zu probieren, das als explizit gesagt nicht so funktioniert, wie du das möchtest.