Am Mittwoch, 23. Oktober 2002 23:05 schrieb David Haller: Danke David für diese email und für Dein Howto des Kernelbauens. Zu diesem SuSE 8.1-Kernel ging schon so viel über diese ML, besonders auch in letzter Zeit die Frage, warum man ein DVD nicht auf Dauer auf DMA schalten kann? Ich habe mit der von SuSE mitgelieferten .config im SuSE-Kernel das make xconfig gestartet und siehe da: dort ist eingestellt, daß nur für die HDDs das DMA gestartet werden soll. Ich habe das "n" in "y" geändert und wollte dann einen neuen Kernel bauen, nein, ging nicht, mit Fehlermeldung abgewiesen ............ Wie kann man denn so etwas ausliefern Gruß von Hans an alle
Hallo,
On Wed, 23 Oct 2002, Philipp Thomas wrote:
Ralf Corsepius
[23 Okt 2002 10:07:53 +0200]: Mit anderen Worten: Der Verantwortliche.
Jein, immer im Zusammenspiel mit unseren Kernel-Spezialisten wie Andrea Archangeli, Andi Kleen, Chris Mason und Jens Axboe (um jetzt nur ein paar zu nennen). Wenn Leute wie Andrea sagen, dass ein Patch in Ordnung ist, wird jemand wie Hubert das akzeptieren.
Hm. Hat Andrea mit IDE zu tun? Oder war das die VM? ;) Andi weiss ich grad nicht, Chris macht u.a. reiserfs, Jens hab ich bisher komplett ueberlesen...
Naja, zur VM bei 2.4.x (mit 1 < x < 12 IIRC) muss ich ja wohl nix sagen. Das war ein eher trauriges Kapitel der Kernelentwicklung... Der Vorwurf dabei gilt _nur_ der Tatsache, dass das so im "stable" Kernel gelandet ist... Und das gleiche gilt nun auch fuer IDE mind. bei den SuSE-Kernels...
Scheint so. Ich habe das IDE-Problem seit SuSE-8.0 und Hubert war seither nicht in der Lage einen bei mir funktionsfähigen Kernel zu liefern
Das Problem ist auch alles andere als trivial, gegeben die Menge an Patches, die wir zusätzlich einpflegen.
Naja, zumindest bei so wichtigen Themen wie VM oder IDE muss ein patch vorher _ausfuehrlichst_ getestet werden!
Das Problem liess sich doch erahnen als sich "viele" "normale" IDE-Maschinen nichmal booten liessen[2]... Wer sowas dann nicht komplett austestet oder auf die alte Version zurueckgreift... Bei mir laeuft der Vanilla-Kernel 2.4.16 anstandslos (und scheinbar auch ein Vanilla 2.4.18 bei anderen), d.h. es _gibt_ eine funktionierende Version der IDE-Treiber (vielleicht nicht fuer _alle_ Plattformen, aber deutlich mehr als bei SuSE 8.1 offenbar!).
Und, schonmal daran gedacht schlicht ein paar Patches weniger anzuwenden??
Oder explizit als "experimentell", aber mit $FEATURE" alternativ(!) anzubieten? Ja, jetzt kommt sicher das Argument, dass ihr dafuer nicht die manpower habt, aber wen soll man denn nun bedienen? Die paar, die unbedingt $NEUESTES_FEATURE wollen (sofern sie davon ueberhaupt wissen), oder die Masse, die einfach nur ein stabiles System will? Evtl. mit dem ein oder anderen _getestetem_ Extra-Feature gegenueber dem Vanilla-Kernel? Ich denke doch mal, eher die "Masse". Und da solltet ihr IMO eine defensivere Patch-Strategie anwenden...
Und ein paar mehr Leute (als "freie Tester") einstellen/bezahlen, wenn moeglich *eg* Und/oder Beta-Phasen drastisch verlaengern...
Der LSB-Kernel läuft, die RedHat-Kernel-2.4.18-14 und 2.4.18-17.8.0 ebenfalls.
Dafür fehlt dem RedHat Kernel die Unterstützung für ACPI 2.0 (zwingend nötig, damit einige aktuelle Rechner überhaupt booten), es gibt Bugs im aio Code, etc.
Na und? ACPI brauch ich nicht, und AIO sagt mir nichtmal was... Interessanter fuer mich waere APIC... Und ich denke, das geht einem Grossteil eurer Kunden so.
Ausserdem ist es ja bekannt, dass Linux nicht immer "auf aktuellster Hardware" laeuft...
IMNSHO sollte Hubert nun die Konsequenzen ziehen ...
ACK. s.o.
Alles in allem hat Hubert seine Aufgabe erstaunlich gut gemacht, gemessen an der schieren Menge an Patches.
Naja... Meist ja schon. Aber s.o. speziell bzgl. IDE, aber auch generell sollte er defensiver Arbeiten und den Mut dazu haben _keine_ Patches anzuwenden.
Habe ich vor Monaten schon getan, doch anders als in der Vergangenheit (in der sich Hubert sehr kooperativ gezeigt hatte), ...
Du hast nicht den Stress erlebt, der hier Dank SL 8.1 und United Linux 1.0 herrschte.
Selbstgemacht, IMO.
Da können die Nerven schon mal blank liegen, zumal wenn dann haufenweise Leute mit Bitte um Hilfe für Probleme mit dem Kernel aus mantel/next kommen, für die es ausdrücklich keinen Support gibt.
... dann kann man die (generell) auch passend abspeisen. Aber NUR, und NUR genau dann, wenn der mit der Distri ausgelieferte Kernel funktioniert, denn sonst bleibt den Usern eben erstmal nur der Versuch einen der mantel/next Kernel zu versuchen (siehe Helga's Geschichte) und zu hoffen, dass dieser besser funktioniert... Und dass dann Fragen deswegen kommen finde ich legitim.
Verstehe ich voll und ganz, zumal auch ich seit SuSE 4.2.1 (zumindest AFAIR :) dabei bin. Jens Axboe, der ja nun ein ausgewiesener IDE-Spezialist ist, hat gerade eine Maschine im direkten Zugriff, die genau diese Probleme mit zwei Platten am gleichen Strang aufweist. Ich hoffe, dass er das Problem einkreisen kann.
IMO hat dieses Problem allerhoechste Prioritaet! Setzt Hubert, Jens und sonstwen dran und s.o.. Oder ihr duerftet (verzoegert![1]) einen Haufen Kunden verlieren! Und das faende ich doch schade...
(Es gibt noch weitere (für mich fatale) Bugs in SuSE-8.1, die für mich derart fatal sind, dass eine weitere Verwendung von SuSE-8.1 für mich kaum noch in Frage kommen dürfte, es sei denn SuSE würde sie in Kürze beheben.)
Als da wären?
Hm. Fatal? Weiss nich. Ein paar vielleicht.
Ich werde Dir die Mail, die ich schon im Mai an Hubert geschickt hatte per PM forwarden.
Ich werde das morgen mal sammeln und dann in Übersetzung ( die meisten unserer Kernelspezialisten sprechen kein deutsch) zur Verfügung stellen.
Falls du nen Uebersetzer oder noch Argumente wie z.B. oben (auf Englisch) brauchst, du kannst dich gerne vertrauensvoll an mich wenden ;)
-dnh
[1] Sowas dauert... Aber dass der SuSE 8.1 default-Kernel (und diverse Alternativkernel von mantel/next) "Scheisse" sind/waren, das spricht sich rum... Und laesst Kunden zu anderen Distris wechseln und haelt andere davon ab, SuSE ueberhaupt erstmalig zu kaufen...
[2] du weisst wo.