Kernel Traffic #100 For 1 Jan 2001

There were 369 different contributors. 162 posted more than once. 0 posted last week too.

Ok, ich habe jetzt Bestätigungen von zwei unabhängigen Leuten (Adam Richter und Kai Germaschewski) welche ganz und gar verschiedene Hardware haben, doch das gleiche Problem: IRQ Routing scheint bei beiden nicht zu gehen.

Es ist in beiden Fällen, weil der PCI device config space bereits einen Eintrag für den Interrupt hat, doch der Interrupt anscheinend nicht auf den IRQ Router geroutet wird.

WARUM das passiert ist unklar, doch kann es verchiedene Gründe haben:

undokumentiertes "Plug'n'Play OS true behaviour"
BIOS bugs. Kein weiterer Kommentar.
Warmstarten eines Betriebssystems, dass Interrupt Routing _setzt_ und ausserdem die PCI config space Sache setzt.

Das Problem könnte ziemlich leicht zu beheben sein, indem man einfach den Test entfernt, wo pci->dev schon gesetzt wurde. Dies, btw, ist auch aus einem anderen Grund wichtig - es lässt sich nicht sagen, dass ein Sleep Event das IRQ Routing deaktiviert; also _müssen_ wir einen Weg finden das Interrupt Routing einzuschalten, selbst wenn wir schon glauben, dass wir den richtigen IRQ haben.

Trotz dem Genannten hat wohl auch Martin recht, wenn er meint, dass es Bugs aus der "anderen Ecke" geben könnte und daher wäre es schlecht, wenn wir den IRQ einfach ausser Betrachtung lassen würden.

Hier ist mein aktueller empfohlener Patch für das Problem.

Adam, Kai, könnt ihr nachschauen ob der Patch das Problem bei euch behebt?

Alle anderen, die Probleme mit PCI Interrupt Routing hatten (scheint bei den "neuen" Devices wir CardBus, ACPI, USB, etc. zu sein), könntet ihr bestätigen, dass dies Sachen behebt oder zumindest bei keinem eine Konfiguration bricht, die vorher lief..

Martin, was hälst du davon? Wir brauchen definitiv so etwas doch sollten wir vielleicht noch ein paar mehr logische Test einbauen?

Kai Germaschewski berichtete Erfolg mit dem Patch, doch Martin Diehl könnte keine Änderung feststellen. Nach einigem technischen hin und her mit Martin bemerkte Linus, " Gut, das braucht also eindeutig noch mehr Arbeit. Danke für die Tests - ich habe nicht die Hardware um das zu testen." Linus schlug wieder einige Lösungen vor, nachdem er einen betroffenen Rechner zur Verfügung hatte und fragte nach Kommentaren, doch der Thread endete ohne zufriedenstellende Lösung.

Dieser Thread handelete von einem netten Austausch zwischen Linus Torvalds und Alan Cox. Einmal sagte Alan, " Um zu verhindern, dass Sachen durcheinander kommen und schwer zu debuggen sind, versuchte ich VM Fixes für 2.2.18 zu vermeiden. Da ich Page Aging laufen habe, bin ich überzeugt, dass wir in 2.2.19 einige VM Sachen heftig aussortieren sollten, " -- und fügte mit einem Grinser hinzu -- " und es soll natürlich schneller als 2.4test sein. " Linus antwortete:

Ahh.. Der Wettkampf beginnt!

Du und ich. Mann gegen Mann.

Offen gestanden, wird jeder der RedHat 7.0 und dessen kaputten Compiler für _irgendwas_ verwendet, Probleme haben.

Ich habe keine Ahnung warum RH sich für diese idiotische gcc-2.96 Release entschieden hat (er war sicherlich nicht von den Technikern bei gcc abgesegnet - die waren selbst unangenehm überrascht darüber) und ich finde es noch seltsamer, dass sie offentsichtlich WUSSTEN, dass der eingesetzte Compiler absolut nicht funktionsfähig war. Sie gaben einen anderen (funktionsfähigen) Compiler bei, der dann "kgcc" genannt wurde.

"kgcc" steht für "kernel gcc", offentsichtlich weil (a) sie kapiert haben, dass ein falsch kompilierter Kernel noch schlechter ist als einige zufällige User-Anwendungen und (b) gcc-2.96 so broken ist, dass es spezielle Bibliotheken für das C++ vtable chunks Handling benötigt, so dass der _funktionsfähige_ gcc nur mit Programmen läuft, die diese Bibliotheken nicht brauchen. Namentlich der Kernel.

Falls es noch nicht klar wurde, halte ich RedHat-7.0 für eine Entwicklungs- plattform als ungeeignet und hoffe, das RH ihren Compiler zu etwas besserem zurückstuft. Er hat augenscheinlich Probleme Sachen wie CVS-Snapshots von X usw. zu kompilieren (und alles was mit gcc-2.96 kompiliert wurde wird wohl kaum mit etwas anderem laufen als mit den kaputten Bibliotheken).

Jakub Jelinek antwortete dass die Bugs gegen RedHat's gcc bereits behoben wurden und Linus meinte, " Das ist gut. Und es ist noch besser, wenn man nicht fast-and-lose mit den ausgelieferten Compiler spielt." Auch Jakub antwortete zu Linus Standpunkt mit den speziellen Bibliotheken, die gcc benötigt: " Jede grosse g++ Release hat eine inkompatible libstdc++ - sogar g++ 2.95.2, wenn es mit den glibc 2.1.x Binaries ge-bootstrapped wurde, ist es inkompatibel zu g++ 2.95.2, dass mit glibc 2.2.x ge-bootstrapped worden ist (libstdc++ nimmt dann andere so-Namen; selbst wenn wir g++ 2.95.2 nutzten waren wir nicht C++ binär-kompatibel mit anderen Distributionen)" . Linus antwortete:

Ja.

Und ich begreife, dass jemand bei RedHat wirklick einen Snapshot brauchte, damit irgendein C++ Code richtig kompiliert.

Doch das warf gleichzeitig C-Stabilität von Bord, da ein nicht besonders gut getesteter Snapshot für eine Haupt-Release verwendet wird.

Meinst du ernsthaft, dass das ein guter Tausch war? Oder schämst du dich nur, zugeben zu müssen, dass RH etwas sehr Dummes getan hat?

Auch Alan Cox antwortete auf Linus erste Posts. In Bezug auf Linus Standpunkt, dass RedHat's gcc nicht von den gcc-Technikern abgesegnet wurde, sagte Alan, dass bis auf zwei Patches von RedHat alle in die Upstream Quellen gegangen sind, was als Billigung von RedHat's Wahl steht. Er fügte hinzu, " Die Namensgebung hat den Leuten aufgestossen und war unglücklich, doch die Absprachen mit den Compiler Leuten bei RedHat wurde mit den besten Absichten gemacht. Wenn wir es 'Red Hat cc' genannt hätten wären die Leute wesentlich aufgeregter gewesen und hätten es missbilligt." Zu der Sache, dass gcc so kaputt sei, dass es spezielle Bibliotheken benötigt, sagte er noch, " Falsch - die C++ vtable Format Änderung ist Teil des beabsichtigten Fortschrittes des Compilers und muss auch getan werden um Standards zu erfüllen. gcc 295 hat auch die internen Formate geändert. Unglücklicherweise sind gcc295 und gcc296 wohl nicht die endgültigen Fassungen. Die Compiler Folks werden wohl nicht irgend- etwas garantieren können bis gcc 3.0 herauskommt, was mit einem stabilen 2.4 zusammentreffen könnte." Linus antwortete:

Wenn du die gcc Leute fragen würdest, ist der Hauptgrund dass sie das selbst als grosse Dummheit ansehehen, dass dieser 2.96 inkompatibel zu der 2.95.x Release _und_ der nachfolgenden 3.0 Release ist.

Und keiner hat die Leute gefragt, die das wissen.

Alan erläuterte, dass gcc 2.95 ein anderes Format hat, gcc 2.96 ein anders und egcs 1.1.2 wieder ein anderes. Also haben alle ein verschiedenes Format von den anderen, nur das 2.96 auch ein C++ Compiler ist. Auch Bernhard Rosenkraenzer antwortete Linus ähnlich wie Alan, " Das gleiche gilt für *alle* gcc Releases. Zum Beispiel ist C++-ABI 2.95.x inkompatibel sowohl mit egcs 1.1.x _und_ der anstehenden 3.0 Release." Doch Miquel van Smoorenburg warf ein:

Ja, aber 2.96 ist ausserdem binär-inkompatibel mit allen nicht-RedHat Distributionen. Und da RedHat _die_ Distro ist, die von kommerziellen Einrichtungen eingesetzt wird um Software zu entwickeln, war das wirklich ein sehr schlechter Zug.

Es gibt hier einfach keine Entschuldigung. Es ist zu offentsichtlich.

Ausser dass du bequemerweise einige Fakten ausser acht lässt.

Someone else moved to 2.95 not RH . In fact some of us felt 2.95 wasnt fit to ship at the time.
We tell vendors to build RPMv3 , glibc 2.1.x
Vendors not being stupid understand that they have a bigger market share if they do that.

Um etwas Aufklärung zu bringen:

Die Linux Development Platform Specification (LDPS) wurde im Juni als ein informelles post-LSB-Treffen einberufen -- zu welchem übrigens RedHat keinen einzigen Stellvertreter sandte -- die Diskussion im Restaurant drehte sich um Sachen wie "Oh mein *GOTT*, RedHat macht gerade etwas absolut Dummes -- sie bringen RedHat 7.0 mit beta/snapshots heraus wo fast alles bis auf den Kernel ziemlich kritisch laufen muss -- und Händler, die in diese Falle treten und mit RedHat 7.0 arbeiten werden nie mit einer anderen Distro arbeiten. Das wird *schlecht* für Linux sein."

Er fuhr fort, "Seit Jim Kingdon Red Hat verlassen hat (er war eine Weile bei VA Linux und ist jetzt bei SGI) nimmt soweit ich weiss keiner bei RedHat an den LSB Treffen teil oder nahm an den zweimal in der Woche stattfindenden Telefonkonferenzen teil, oder nahm irgendeine Anstrengung auf sich, das LSB zu einem Ergebniss zu führen. Alan partizipiert an der Mailing-Liste und gibt recht hilfreiche Kommentare aber das ist - soweit ich weiss - auch schon alles mit der LSB-Teilnahme oder Mitarbeit an der LDPS. Da ich einer bin, der Zeit und Arbeit in das LSB gesteckt habe, fände ich es gut, wenn Red Hat etwas mehr in das LSB stecken würde; Ich (und sicherlich all die anderen LSB Voluntäre) würden einen grösseren Level an Anteilnahme für Red Hat erhalten."

Ein anderer Thread zweigte von Alan's anfänglicher Antwort auf Linus erste Post ab. Zu Linus Hoffnung, dass Red Hat ihren gcc so schnell als möglich downgraded meinte Alan:

Zu welcher Version - gcc 2.5.8 ? Das Problem ist nicht, dass der Snapshot mehr Bugs hat als davor, sondern das die Bugs an verschiedenen Stellen auftreten. egcs und gcc295 haben beide Kompilierungsprobleme mit X.

Ich rate immer noch den Leuten: Nehmt egcs-1.1.2 für Linux 2.2.x. Es ist möglich 2.2.18 mit einem gcc-2.9.6 zu erstellen aber für Produktions-System würde ich das persönlich nicht machen - NICHT weil gcc296 mehr Bugs hat, sondern die Bugs an verschiedenen Orten liegen und fest glaube, dass die Leute von Produktions-Systemen die schuldigen Burschen selbst finden sollten ;)

gcc-2.95.2 ist zumindest eine echte Release - von einem Abzweig der aktiv gemaintaint wird - also wird es wohl schon bald einen 2.95.3 geben, der soviele Fehler behebt wie möglich _ohne_ inkompatibel wie die Snapshots zu sein.

Oder bleibe einfach bei 2.91.66 (egcs).

Ich applaudiere, dass RedHat Snapshots verfügbar macht, doch sollten sie diese als SNAPSHOTS kennzeichnen und nicht als den Haupt-Compiler ohne jede Chance die Probleme, die er verursacht, zu beheben.

So wie es ist, ist vielleicht jeder der entwickelt mit RH-6.2 besser beraten. Das ist doppelt richtig, wenn man vorhat Binaries herauszugeben.

Alan führte an, dass 2.96 aktiv unterstützt wird -- von CygnusHat -- und dass die alle Änderungen an das gcc Core Team zurückgeben. Zu dem mit den Snapshots als SNAPSHOTS zu markieren sagte er, " Das es verwirrend und von einigen offiziellen GNU Releases falsch verstanden wurde war nie in unserer Absicht und wir haben uns auch dafür entschuldigt. Es wurde ohne böse Arglist getan." Und zu der Empfehlung, dass Entwickler RedHat 6.2 der 7.0-Version vorziehen sollen sagte er, " Wir empfehlen wirklich, dass Leute 6.2 nutzen sollen, wenn Binaries damit entwickelt und vertrieben werden sollen, bis sie glibc 2.2 wirklich brauchen. Das ist die gleiche Richtlinie wie der des LSB 'oops, die wir noch nicht abgeschlossen haben."

Für alle, die interessiert darin sind, es gab eine Erwähnung der 2.96 Instabilität in BROKEN KCREF. 2.96 wurde immer noch nicht empfohlen in BROKEN KCREF (obwohl Alan glaubte, dass das mehr ein Problem des Kernels als des Comilers sei). Horst von Brand stimmte damit überein in BROKEN KCREF, obwohl RedHat bereits ihren gcc Snapshot under den falschen Namen 2.96 veröffentlichen zu wollen; und Peter Samuelson meinte, dass 2.96 mit keinem bekannten Kernel laufen würde, in BROKEN KCREF.

Einer bemerkte, dass der kapm-idled Prozess normalerweise zwischen 60% und 80% der CPU belegt, aber nur wenn keine anderen Prozesse laufen. Rik van Riel sagte, " Für was meinst du steht das "idled" in "kapm-idled"?" Nick Holloway antortete, " Wir wissen, dass es ein Versuch war, dass die Leute sich beschweren wenn "kapm" die CPU herunterzieht. Schaut so aus, als ob es nicht funktioniert." Der Original Poster anwortete Rik und sagte, dass das Verhalten irreführend ist und eine konstante ausgelastete CPU anzeigt. Und Kurt Garloff meinte, " Noch schlimmer: Einst konnte man das Ergebniss aus dem System-Teil der Auslastung folgern. Das ist nicht mehr möglich jetzt. Ich mag das jetzt auch nicht und halte es für einen kosmetischen Bug. (Was wesentlich besser als ein echter Bug ist, versteht mich nicht falsch. Aber wenn das Lösen eines kosmetischen Bugs einen echten hervorruft: Lass die Finger davon!)." Es gab einige Vorschläge, die Situation zu verbessern doch es kam nichts mehr Wesentliches von der Liste. Ein frühere Diskussion findet man auf BROKEN KCREF.

Rasmus Andersen postete einen kleinen Patch, der das 'static' der cfi_probe Struktur entfernt, was ihn sonst als gemeinsam benutzten Bereich verhindert hat. Wenn man das herausnimmt, kann der Kernel erfolgreich den Link-Vorgang vollziehen, obwohl Rasmus nicht sicher war, ob das Verhalten, dass sein Patch ändert, vielleicht so beabsichtigt wurde. Keith Owens antwortete, dass jemand zwischen test11 und test12 Code hinzufügte, um eine bedingte Kompilierung durchzufüren - was wie er meint unnötige Komplexität beinhaltet und damit falsch sei. Er erklärte, dass diese rückgängig gemacht werden sollte und die cfi_probe wieder als static deklariert werden soll. Doch David Woodhouse verteidigte die Änderung und meinte, die bedingte Kompilierung sei nötig um verschiedene Variationen in der Link-Reihenfolge anzupassen. Dazu meinte Keith, " Mit einer bedingten Kompilierung herumzuhantieren, damit die Link Reihenfolge eingehalten wird ist die falsche Lösung. Das mtd/Makefile muss die Objekte in der richtigen Reihenfolge einlinken." Er listete auf, was die richtige Reihenfolge der betroffenen .o Dateien sein müsse, doch David teilte diese Meinung nicht und erklärte:

Die bedingte Kompilierung ist weitaus klarer für Leute als die spitzfindige Sache mit der Link-Reihenfolge. Also ziehe ich die letztere Lösung unbedingt vor.

Ich muss bedingte Kompilierung in meinem Tree machen, um es unter 2.0 uClinux kompilierfähig zu halten. Zugegebenermassen wird das nicht in 2.4 kommen, doch ziehe ich eindeutig vor, dass der Code 2.4. so nahe wie möglich an meinen Tree ist.

Ich werde das angehen und mit einer saubereren Lösung kommen. Es könnte so aussehen, dass ich allen Bedingungssachen in compatmac.h schiebe und den 'echten' Code Pfad in einem saubereren Status als bisher lasse.

Keith meinte, "Der Rest des Kernels hängt ohnehin bereits völlig von jenen "raffinierten" Sachen der Link Reihenfolge ab. Weshalb sollte mtd anders sein?" Alan Cox sagte, " Warum sollte mtd broken sein, nur weil es alle anderen Makefiles sind?" Und David beantwortete die Frage mit, " Da ich den MTD Code maintaine und ich will es so. Ich meine die Link-Reihenfolge Abhängigkeiten sind eklig, unnötig und weitaus problematischer als die Alternativen. Ich werde eine Alternativen implementieren, die sauberer ist als der jetztige Code und Linus kann den Patch akzeptieren oder nicht, wir er meint." Keith argumentierte, " Dein Entscheidung. Aber beachte, dass wenn CONFIG_MODULES=y ist und mtd im Kernel ist, dann _muss_ mtd eine korrekte Link-Reihenfolge haben. Stell dir eine Konfiguration vor mit CONFIG_MODULES=y aber jede mtd Option ist auf 'y', die Link-Reihenfolge ist dann kritisch. Die Folge aus der Konstellation wenn dann 2 oder mehr mtd-Module eingebunden sind ist, dass du auf der Reihenfolge festhängst, egal was du tust. Natürlich kannst du eine eigene Methode einführen und maintainen, um die mtd Initializations-Reihenfolge zu kontrollieren..." David gab zu, dass er keine Antwort zu diesem Problem habe und erklärte, " Der Patch wurde tatsächlich von einem eingeführt, um 2.0 Kompilierung zu fixen - dort bemerkte ich, dass es das Link-Reihenfolge Problem für bestimmte Konfigurationen behebt. Ich werde versuchen einen sauberen Weg zu finden, dass der mtd Code in allen Konfigurationen läuft ohne das obige tun zu müssen. Falls es wirklich dazu kommt, das oben genannte tun zu müssen, werde ich eventuell aufgeben und es zusammen mit dem Kernel Code, von dem du sagst, dass er auch Link-Reihenfolge Abhängigkeiten hat, als 'broken' markieren. " Ende des Threads (tm).

Im Laufe der Diskussion, fragte Brady Montz nach Dokus, welche die Vorteile von NFSv3 aufzeigen. Alan Cox antwortete, " Nicht aus der Hand, aber ich kann dir eine sehr kurze Zusammenfassung von den Haupt- vorteilen geben - Schreibgeschwindigkeit. NFSv2 hat synchrone Schreibzugriffe mit minimalen Overhead. NFSv3 sammelt Schreibzugriffe auf dem Server und verteilt sie wie der Server will. Der Client sendet Schreib-Anforderungen, doch bevor er sie als abgeschlossen und damit sauber vorraussetzt, muss der Teil seines Caches das bestätigen. Normalerweise kommt die Bestätigung nachdem die I/O Zugriffe des Servers geschrieben wurden, wenn nicht wartet es." und Andrea Arcangeli fügte hinzu, " Ein anderes relevantes Feature ist, dass mit 2.4.x und 2.2.18aa2 man auch 2GB Dateien per NFSv3 ansprechen kann (wie bei ext2)."

Richard B. Johnson bemerkte etwas, was wie ein Performance Problem im Virtual Memory Subsystem der Kernel 2.2.17, 2.4.0-test9 und 2.4.0-test12 aussieht. Er schrieb ein Testprogramm, dass Speicher alloziert (via malloc()), benutzt und wieder freigibt. Ihm fiel auf, dass der gesamte Speicher schnell und effizient freigegeben wird, wenn er aus dem Programm mit CTRL-C herausgeht, während wenn das Programm seinen eigenen Dealloziierungs-Modus erreicht, " es sogar bis zu einer Minute dauern kann!! Wärhenddessen findet auch hohe Swap-Aktivität statt. Da viele Programme Daten mit malloc() über die Rücksprungadresse allozieren/freigeben ist dies ein ernsthaftes Leistungsloch. Diese Aktivität sollte nur dann auftreten, wenn irgendetwas ausgelagert oder wieder zurückgeholt wird, aber nichts wird während einer Freigabe zurückgeholt! Da Pages im Userland nicht neu angeordnet werren (oder nicht sollten) sollte es keine Swap- Aktivität während einer Page-Freigabe geben." David S. Miller fragte, " Wie werden diese Puffer genau alloziert/freigeben? Bist du abolut sicher, dass eine Freigabe nicht von den Puffern lädt oder in sie speichert wie eine free(3)-Implementation es machen würde? Das würde die Pages dazu führen, dass sie vom Swap-Bereich zurückgeholt werden. " Richard antwortete, dass er einfach free() nutzte, wie ein typisches Userland-Programm es macht. Doch David antwortete: " malloc und free managen ihre freien Puffer-Bereiche mit verketteten Listen, also speichert ein free() zwei der (2 * sizeof(void *)) Bytes vor und nach jenem Puffer. Daher das Swapping. Nimm direkt mmap()/munmap() und verwalte Dinge komplett selbst um dieses Verhalten loszuwerden."

Alan Cox hat seit kurzem seinen eigenen Patch-Tree gegen den 2.4-test Tree gestartet und gibt einige Linus Torvalds für offizielle Entwickler- Versionen. Er veröffentlichte 2.4.0test13pre3-ac1 und sagte, " Das ist hauptsächlich dafür da, dass Leute sehen, was in meinen Tree neu hinzukam und was abging. Der Patch für die Abenteurer ist in ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4.0test/" Er gab seinen Changelog:

Handle TLB flush reruns caused by APIC rexmit (me)
Fix leak in link() syscall (Al Viro)
Fix ramfs deadlock (Al Viro)
Fix udf deadlock (Al Viro)
Improve parport docs (Tim Waugh)
Document some of the macros (Tim Waugh)
Fix ppa timing issues (Tim Waugh)
Mark the parport fifo code as experimental (Tim Waugh)
Resynch ppa changelog | Tim please double check as I got offsets (Tim Waugh)
Fix Yam driver for Linux 2.4test (Hans Grobler)
Fix AF_ROSE sockets for 2.4 (Hans Grobler)
Fix AF_NETROM sockets for 2.4 (Hans Grobler)
Tidy AF_AX25 sockets for 2.4 (Hans Grobler)
Teach kernel-doc about const (Jani Monoses)
Add documentation to the PCI api (Jani Monoses)
Fix inode.c documentation (Jani Monoses)
Push Davicom support into the main tulip driver (Tobias Ringstrom)
First block of mkiss driver fixes (Hans Grobler)
Fix bug in VFAT short name handling (Nicolas Goutte)
Clean up the i810 driver (Tjeerd Mulder)
RCPCI45 PCI cleanup fixes (mark 2) (Rasmus Andersen)
Improve the ALSxxx sound driver documentation (Jonathan Woithe)
Fix ext2 modular build (Jeff Raubitschek)
Fix bug in scripts/Configure.in matching (Matthew Wilcox)
Revert accidental amifb change (Geert Uytterhoeven)
Fix ext2 file size limiting for large files (Andreas Dilger)
Clean up misleading indenting in partition code (JAmes Antill)
Update SiS video drivers (Can-Ru Yeou)
Yamaha audio doc fix (Pavel Roskin)
Fix ACPI driver wakeup races (David Woodhouse)
Remove bogus asserts in 8139too driver (Jeff Garzik)
Fix timeout problms with rocktports at 249 days
Update acenic patches (Jes Sorensen)
Fix i810 tco locking (me)
Fix media makefiles (me)
Fix drm makefiles (Peter Samuelson)

Die Serial ATA specification (500 Seiten) ist ab jetzt erhältlich; für die Öffentlichkeit gegen bestimmte "click-to-accept" Konditionen. Ein Klick auf den "specification" Link am Ende der Seite bei http://www.serialata.org/. Ich hoffe die Konditionen sind akzeptierbar. Die Datei ist ein gezipptes MS Word- Dokument.

John Reiser gab bekannt, "Die Beta release v1.11 des UPX executable compressor http://upx.tsx.org bietet neue, dichtere Re-Kompression komprimierter Linux Kernel für x86. Zusätzliche Platzersparnisse von ca. 15% wurden mit "upx --best vmlinuz" erzielt (Beispiel: 617431 ==> 525099, spart 92332 Bytes). Sowohl Quellen (GPLv2) als auch vor-kompilierte Binaries für den x86 sind erhältlich, " Adrian Bunk erläuterete, dass das Projekt nicht völlig GPLed ist, doch eine eigene Ausnahme für einen Teil der Binaries hat. Er gaben einen link zum Lizenstext, doch Frank v Waveren und John argumentierten, dass das lediglich ein Fall von Dual-Lizensierung ist, keine zusätzlichen Einschränkungen also.

Einer gabe einen Link auf einen Artikel von theregister, bei dem es um Hardware-basierenden Kopierschutz geht. Er sagte die Technologie sei einfach abzuschmettern, doch Alan Cox meinte, " Vielleicht wird das sehr schwer abzuschmettern sein. Es heisst auch in der jetzigen Form, dass man Disk Defragmentierer wegschmeissen kann. Tot, aus. Willkommen zu den United Police State of America. Ich warte nur auf ein paar Gemeinschaftsklagen gegen Platten-Hersteller, wenn die Backup Tools der Leute nicht mehr damit fertig werden." Zu dem letzten Satz antwortete Andre Hedrick:

Das ist eins der Themen, die ich unter anderem mit vielen anderen während der Dezember Plenary Sitzung anschnitt. Ich konnte das Thema durch meine Vorschläge soweit vertiefen, dass die Anpassung 60 Tage lang verschoben wurde. Dieses Thema wird wieder im Februar aufkommen. Weil ich nur meine Interessen als Berater des T13 Komitees vertreten kann, da es keine Organisation namens "Linux" im offiziellen Sinn gibt.

Ich schätze, dass ich auf CPRM gewaltig Dampf machen werde, doch weiss hier jeder, dass ich sowiel machen werde wie ich auftischen kann! Wenn ihr mir einen Bericht senden wollt, um euch über das Ganze zu beschweren, würde ich diese Punkte mit zu meinem Treffen nehmen.


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

1.	5 Dec 2000 - 18 Dec 2000	(15 posts)	IRQ Routing Problems In Developer Series
2.	7 Dec 2000 - 8 Dec 2000	(23 posts)	2.2 Vs. 2.4
3.	7 Dec 2000 - 17 Dec 2000	(78 posts)	Argument Over Quality Of Red Hat 7.0
4.	11 Dec 2000 - 22 Dec 2000	(18 posts)	kapmd Hogging The CPU: The Saga Continues
5.	16 Dec 2000 - 17 Dec 2000	(13 posts)	Link-Order Dependency Problems
6.	17 Dec 2000 - 18 Dec 2000	(5 posts)	Benefits Of NFSv3
7.	18 Dec 2000	(4 posts)	VM Performance Issues Regarding Memory Allocation
8.	18 Dec 2000	(8 posts)	Alan's 2.4 Tree
9.	18 Dec 2000	(3 posts)	ATA Specification Available With Click-Through Licence
10.	20 Dec 2000 - 21 Dec 2000	(5 posts)	Achieving Greater Compression In Kernel Binaries
11.	20 Dec 2000 - 22 Dec 2000	(3 posts)	Hardware-Based Copy-Protection

Kernel Traffic #100 For 1 Jan 2001

By Zack Brown

Translated By: Florian Zimmermann