>Torvalds deutete auch an, dass das OSDL versärkt bei Herstellern für einem besseren Treibersupport zur Unterstützung von Laptops und 3D-Grafik werben werde.
Von Jochen Schmitt am Fr, 4. Februar 2005 um 11:47 #
Er sollte auch für ein stabileres Kernel-API werben. IMHO ist es unzumitbar, wenn in einem stabilen Kernelrelease das interne API in einer Weise geändert werden, dass das Compilieren von externen Kernelmodulen fehtschlägt.
Bisher ist die Linux-Philosopie, dass sich alle Module im Kernelbaum befinden. Solange da keine Änderung geplant ist, macht es keinen Sinn, die interne! Kernel API zu stabilisieren.
Die externe API des Linux Kernels ist übrigens extrem stabil: Ich kann immer noch Binaries im a.out Format von 1995 laufen lassen.
Von energyman76b am Fr, 4. Februar 2005 um 19:27 #
tja, wenn linux eine stabile Treiber-Api hätte, hättest du vielleicht recht.
Da man sich aber mit Absicht nicht um sowas schert, auch um Entwickler externer Module zu 'zwingen', ihre Treiber zu integrieren, und die Philosophie herrscht, was gemacht werden muß, wird gemacht, kannst du lange jammern.
Außerdem sagst du es ja selbst: 'interne API'.
Was du damit wohl meinst ist, Mechanismen zu benutzen, die dafür nie gedacht waren.. und die 'externen APIs' sind stabil. Schließlich läuft Quake immer noch auf L. Oder?
Da man sich aber mit Absicht nicht um sowas schert, auch um Entwickler externer Module zu 'zwingen', ihre Treiber zu integrieren, und die Philosophie herrscht, was gemacht werden muß, wird gemacht, kannst du lange jammern.
Tja, und das ist ein grosser Fehler! Ohne die Unterstuetzung der Hardwarehersteller wird es Linux beim Endverbraucher sehr schwer haben. Und die bekommen sie nicht, solange die Treiber-ABI nicht stabil ist. Die wollen nunmal nicht ihre Treiber offenlegen. Punkt.
Von Jörg W Mittag am So, 6. Februar 2005 um 15:15 #
IMHO ist es unzumutbar, wenn immer nur gejammert wird, statt einfach etwas zu tun. Linux ist ein freies Betriebssystem, falls irgendjemand der Meinung ist, dass er eine stabile Treiber-ABI braucht, dann soll er eben eine schreiben. Wenn anstatt der ganzen Jammer-Mails genau so viel Code geschrieben worden wäre, dann häte das locker nicht nur für eine stabile Treiber-ABI sondern auch gleich für ein ganzes neues Betriebssystem gereicht — und das ist auch notwendig, denn eine stabile Treiber-ABI ist bei einem freien Betriebssystem schon prinzipbedingt unmöglich.
Ist mir etwas peinlich, aber kann das auch heißen, das in Zusammenarbeit mit VM-Ware die Emulation von anderen Betriebsystemen weniger Ressourcen braucht?
Soweit ich das verstanden hab ist XEN (http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html) hauptsächlich ein Kernelpatch der es dir erlaubt auf einem XEN-Linux-System mehrere Domains (Virtuelle Systeme ähnlich wie bei AIX) mit unterschiedlichen Linux-Kerneln bzw. NetBSD zu betreiben.
Die Integration der Virtualisierungsmöglichkeit in den Kernel wäre wirklich gut. Damit läßt sich sowohl auf der Server- als auch der Desktopseite einiges anfangen und das von Haus aus. Z.B. endlich die Parallelinstallation eines noch vorhandenen Redmond-Systems loswerden. Das wird dann bei Bedarf (der bei mir kaum noch da ist) nur noch temporär gerufen und verschwindet genauso schnell, wie es gekommen ist ;-) Oder gefahrloser Test von Distributionen oder anderen OS, so unterstützt.
Frage: wer von den geneigten Lesern hat XEN schon getestet. Wie sieht es mit der HW-Unterstützung (USB/Firewire) und den Netzwerkfähgkeiten aus?
Mit Redmond wirds wohl nix. Laut Xen-Manual muss das OS auf einen Betrieb mit Xen vorbereitet sein. (The drawback of this approach is that it requires operating systems to be ported to run on Xen) Link: http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/user/user.html
Von Jörg W Mittag am So, 6. Februar 2005 um 15:06 #
Windows XP wurde als eine Art Proof-of-Concept auf eine vorherige Version von Xen portiert. Es wäre wohl auch kein Problem, es auf aktuelle Versionen zu portieren, aber das wäre sinnlos, da Microsoft den Vertrieb einer solchen Portierung niemals erlauben würde. Sonst wäre der Kauf von Connectix schließlich rausgeschmissenes Geld gewesen (-;
Durch Hardwareunterstützung lässt sich das Problem umgehen. Intel und AMD haben bereits entsprechende Prozessoren angekündigt. Dadurch lassen sich unmodifizierte Systeme unter Xen booten.
Naja. Windows laeuft zwar, aber die Entwickler sehen da wohl Lizenzprobleme ... ;-)
Was aber die Funktionisfaehigkeit von Linux als Gast-OS angeht: Echt prima.
Vor allem, dass die Netzinterfaces als Bridge emuliert werden, ist fuer IP-basierte Dienste von sehr grossem Vorteil. Die RAM-Zuteilung ist mir noch nicht ganz klar. Bisher hab ich das nur statisch hinbekommen, auch wenn es wohl semidynamisch gehen soll.
Die Filesysteme kann man per NFS, per Loopback-File oder per native-Durchgriff einbinden. Mit ein wenig Nachdenken (gemeinsames /usr fuer alle OS-Partitionen) spart man auch viel Platz.
Wir haben hier einen Athlon 2200 mit 512 MB Ram, der 8 OS-Partitionen parallel laufen laesst.
Von Daniel Baumann am Fr, 4. Februar 2005 um 17:39 #
UML ist ein Hack der nur fuer genau einen|mehrere Linux-Instanzen funktioniert/vorgesehen ist. XEN implementiert eine allgemeine Loesung, die Linux zu einem Gast System erweitert, das im Prinzip von jedem anderen (minimal angepassten) Betriebssystem benutzt werden kann.
Nach dem was ich verstanden habe ist XEN eine saubere Lösung, die auch andere OSe relativ problemlos (nach 'kleinen Modifikationen') erlaubt...
Ob Windows damit laufen wird, halte ich für unwahrscheinlich, schließe es aber nicht aus... (wird aber closed source bleiben - für den Endanwender zumindestens)
Ich würde mir ja schwerst wünschen, das Eigentümervererbung bei Dateien (setuid dir) mal fester Bestandteil des Kernels wird. Kann man darüber irgendwo abstimmen ?
ob "ausgewachsene" Server oder embedded Systeme, wenn man einen Fehler beim Systemupgrade macht kann man sich aussperren, besonders wenn man weit von dem Server entfernt ist.
Grub kann kein SSH und AFAIK kann man Grub nicht auf allen Systemen verwenden.
Ich suche eine Möglichkeit mit einem MinimalLinux mit SSH2 einen anderen Kernel booten zu können (und dabei das MinimalLinux zu beenden.) XEN hört sich sehr interessant an, aber z.B. für embedded Lösungen ist dies wohl nichts *g*.
wenn man für 65 Euro ein Linksys WRT54g erwirbt und dort eigene Kernel ausprobiert ist ein kvm nicht nur _deutlich_ teurer, sondern hift auch nichts, wenn etwas schief geht. Aber auch für andere Fälle dürfte kexec ein _nettes_ tool sein.
Von Daniel Baumann am Sa, 5. Februar 2005 um 00:41 #
<meine meinung>
"wenn man für 65 Euro ein Linksys WRT54g erwirbt"
spielen solche dinge sowieso keine rolle, da home-betrieb.
"und dort eigene Kernel ausprobiert"
beim 'ausprobieren' hat man lokalen zugriff auf das geraet. abgesehen davon sollte man mit solchen dingern nicht rumspielen, wenn man a) darauf angewiesen ist, dass sie hohe verfuegbarkeit haben und b) wenn man keine ahnung hat. ergo ergibt sich keine situation, wo das noetig ist (ganz allgemein festgehalten - nicht auf jemand bestimmten bezogen).
ich hätte Dir allgemeiner Antworten sollen: "JUST FOR FUN"
Außerdem ist b) Deiner Meinung ein Dogma, welches nicht zur Verbreitung von Wissen, Erfahrung und allgemein Linux beiträgt.
Grub läuft nicht überall und hat kein SSH2. Der WRT54g ist ein Beispiel für ein Flashvorgang, bei dem ein Fehler zu einem unbenutzbarer Kiste führen kann (Je nach Modell und Erfahrung). Wie will man für embedded Geräte entwickeln oder hacken? Xen läuft da nicht und Hardwareemulatoren??? Hat man ersteinmal einen simplen Kernel mit kexec erfolgreich geflasht, kann man sich ohne großen Zeitverlust und ärger weiter "vortasten".
Auch gibt es Einsatzideen und Möglichkeiten, bei dem man kein kvm einsetzen kann/will (Wetterstation, Raumsonde,.....) so daß Deine Reaktion fast nahelegt, das Du betroffen wärest, wenn man weniger kvms kaufen würde.
Für Interessierte empfehle ich diesen IBM Artikel: http://www-106.ibm.com/developerworks/linux/library/l-kexec.html
Wichtigeste news: "Kexec is currently available on the x86 32-bit platform only." Hmm IMHO wären gerade nicht x86 - die embeddet Plattformen interessant - was nicht ist könnte noch werden.
Da der neue Kernel komplett in das Ram geladen wird, und dann gestartet wird könnte man mit einem kexec-Kernel ein System von einem FS booten, das der orginale Bootloader nicht mounten kann - USB oder gar übers Netzt. Wenn man Systemen 1-4 MB Flash onboard spendieren würde bräuchte man zukünftig nur eine Internetverbindung um den aktuellsten Installer seiner Wunschdistribution starten (Natürlich über eine Sichere Verbindung und einer Signierungskeyüberprüfung). Usw.
IMHO hat kexec hat eine Menge Potential und ist eine Ergänzung (in andere Richtungen) zu den Möglichkeiten von XEN.
Von Gunter Ohrner am So, 6. Februar 2005 um 14:53 #
Mh, und du musst auf dem WRT neue Kernel ausprobieren, ohne direkten Zugang zu dem Gerät zu haben? Ansonsten kauf dir halt 2, einen zum Testen neuer Kernel, der an deinem Schreibtisch steht und den du jederzeit über boot_wait tftp neu flashen kannst wenn nix mehr geht, und einen den du auf's Hausdach montierst (oder wohin auch immer) und nur mit getesteter Firmware flashst.
Von Matthias Bläsing am Fr, 4. Februar 2005 um 22:40 #
Ich bin mir nicht mehr ganz sicher, aber irgendwo habe ich davon gelesen, dass es einen Patch geben, der: 1. einen neuen Kernel von der Festplatte lädt 2. ihn in den RAM kopiert 3. das System mit diesem Kernel neustartet
Wäre also das was du willst. Wichtig ist noch, dass dabei selbstverständlich das laufende System (inklusive aller Prozesse) stirbt.
das alle alten Prozesse dabei sterben ist bei z.B. 16 MB Ram Systemen _kein_ Nachteil, sondern sehr erwünscht. ;)
kexec ist der Patch, den ich gesucht habe. Habe eben durch andere Postings einwenig gesucht und war auch auf kexec gestoßen.
Ohne Wertung einpaar Treffer: http://lwn.net/Articles/15468/
"Kexec is a patch to the Linux kernel that allows you to boot directly to a new kernel from the currently running one. Kexec skips the entire bootloader stage and directly jumps into the kernel that the user want to boot to. There is no hardware reset, no firmware operation, and no bootloader involved. The weakest link in the boot sequence, the firmware, is completely avoided. The big gain from this feature is that system reboots are now extremely fast."
Ich habe an einem meiner Computer einen Festfrequenz-Monitor von HP. Die Betriebsystem-Wahl über Grub muß ich mir aber an einem anderen Monitor ansehen (möglich dank Matrox G450 DH). Hat jemand eine praktikable Idee (Loadlin mit Vesa-Treiber fänd ich nicht so toll).
- Grub mit einer seriellen Console und einem alten Palm (die benutzung der großen Tastatur wäre warscheinlich dann noch zu hacken...) http://www.gnu.org/software/grub/manual/grub.html#Serial%20terminal - Bootdiskette für eins der OS - Kexec --gibt es einen Bootloader mit Sprachausgabe?? ;) Gruß rob
Danke erstmal. Eventuell läßt sich ja auch der Turbo-Button umfunktionieren - oder ich lege statt einer /boot - doch eine DOS - Partition an. Dann würde ich von Win2k auf Win98 umsteigen - brauch ich ja eh nicht sehr häufig.
Nachdem meine Videograbberkarte jetzt hervorragend unter Linux läuft, fliegt Windows evtl. auch komplett runter - muß mal sehen. Ist eigentlich nur noch Fritz als Windows-Programm wichtig.
Von Jörg W Mittag am So, 6. Februar 2005 um 15:55 #
Hi,
es gab ja in den letzten Monaten viele Diskussionen darüber, wie Xen am besten implementiert werden soll. Momentan ist Xen eine eigene Architektur in /arch/xen, wobei — ähnlich wie bei x86_64 — diverse Dateien aus /arch/i386 mitbenutzt werden.
Einige Entwickler fanden, dass Xen nicht verschieden genug von i386 sei, um eine eigene Architektur zu sein und es in i386 integriert werden solle, bevor es in Andrew Mortons Kernel aufgenommen wird. Andere meinten, man solle es erst in Andrew Mortons Kernel aufnehmen und dann nach und nach in i386 integrieren. In beiden Fällen war die Begründung, dass es derzeit eine Menge doppelten Code in i386 und Xen gibt und doppelter Code immer Wartungsprobleme mit sich bringt.
Wieder andere Entwickler wiesen darauf hin, dass bereits an einer Portierung von Xen für x86_64 gearbeitet wird und eine für PowerPC in Planung sei und wenn man dann diese Portierungen wiederum in x86_64 und ppc integrierte, hätte man wiederum den Xen-spezifischen Code doppelt oder gar dreifach. Also sollte man Xen aufsplitten und den generischen Code in /arch/xen und den plattformspezifischen Code in z.B. /arch/i386/xen unterbringen.
Die ganz ambitionierten weisen dann noch darauf hin, dass es bereits zwei VM-Architekturen in Linux Torvalds "Mainline"-Kernel gibt (s390 und ppc64) und man bevor eine dritte hinzugefügt wird, erstmal die drei zu einer generischen VM-Architektur vereinheitlichen sollte.
Die Frage ist jetzt: weiß jemand, für welches Modell man sich jetzt entschieden hat?
Das ist doch mal schönens was man da hört
mfg: Jochen Schmitt
Bisher ist die Linux-Philosopie, dass sich alle Module im Kernelbaum befinden. Solange da keine Änderung geplant ist, macht es keinen Sinn, die interne! Kernel API zu stabilisieren.
Die externe API des Linux Kernels ist übrigens extrem stabil: Ich kann immer noch Binaries im a.out Format von 1995 laufen lassen.
ich net. stichwort soundsystem .......
Da man sich aber mit Absicht nicht um sowas schert, auch um Entwickler externer Module zu 'zwingen', ihre Treiber zu integrieren, und die Philosophie herrscht, was gemacht werden muß, wird gemacht, kannst du lange jammern.
Außerdem sagst du es ja selbst: 'interne API'.
Was du damit wohl meinst ist, Mechanismen zu benutzen, die dafür nie gedacht waren.. und die 'externen APIs' sind stabil.
Schließlich läuft Quake immer noch auf L. Oder?
Tja, und das ist ein grosser Fehler! Ohne die Unterstuetzung der Hardwarehersteller wird es Linux beim Endverbraucher sehr schwer haben. Und die bekommen sie nicht, solange die Treiber-ABI nicht stabil ist. Die wollen nunmal nicht ihre Treiber offenlegen. Punkt.
jwm
wird auch langsam zeit! linux lauft nicht zufriedenstellend auf laptops und ist mithin also keine mobile alternative.
hEAdr00m (profi und sprachrohr)
Ich würde das sehr begrüßen, :D
/ajk
Damit läßt sich sowohl auf der Server- als auch der Desktopseite einiges anfangen und das von Haus aus.
Z.B. endlich die Parallelinstallation eines noch vorhandenen Redmond-Systems loswerden.
Das wird dann bei Bedarf (der bei mir kaum noch da ist) nur noch temporär gerufen und verschwindet genauso schnell, wie es gekommen ist ;-)
Oder gefahrloser Test von Distributionen oder anderen OS, so unterstützt.
Frage: wer von den geneigten Lesern hat XEN schon getestet.
Wie sieht es mit der HW-Unterstützung (USB/Firewire) und den Netzwerkfähgkeiten aus?
MfG
(The drawback of this approach is that it requires operating systems to be ported to run on Xen)
Link:
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/user/user.html
jwm
Intel Vanderpool
Längerfristig (schätze ca. 1-2 Jahren) wird wohl Windows unter Xen lauffähig sein.
Was aber die Funktionisfaehigkeit von Linux als Gast-OS angeht: Echt prima.
Vor allem, dass die Netzinterfaces als Bridge emuliert werden, ist fuer IP-basierte Dienste von sehr grossem Vorteil.
Die RAM-Zuteilung ist mir noch nicht ganz klar. Bisher hab ich das nur statisch hinbekommen, auch wenn es wohl semidynamisch gehen soll.
Die Filesysteme kann man per NFS, per Loopback-File oder per native-Durchgriff einbinden.
Mit ein wenig Nachdenken (gemeinsames /usr fuer alle OS-Partitionen) spart man auch viel Platz.
Wir haben hier einen Athlon 2200 mit 512 MB Ram, der 8 OS-Partitionen parallel laufen laesst.
Vom Konzept her dürfte da ja sehr ähnlich sein
Nach dem was ich verstanden habe ist XEN eine saubere Lösung, die auch andere OSe relativ problemlos (nach 'kleinen Modifikationen') erlaubt...
Ob Windows damit laufen wird, halte ich für unwahrscheinlich, schließe es aber nicht aus... (wird aber closed source bleiben - für den Endanwender zumindestens)
Gruß
Barkpingu
ob "ausgewachsene" Server oder embedded Systeme, wenn man einen Fehler beim Systemupgrade macht kann man sich aussperren, besonders wenn man weit von dem Server entfernt ist.
Grub kann kein SSH und AFAIK kann man Grub nicht auf allen Systemen verwenden.
Ich suche eine Möglichkeit mit einem MinimalLinux mit SSH2 einen anderen Kernel booten zu können (und dabei das MinimalLinux zu beenden.) XEN hört sich sehr interessant an, aber z.B. für embedded Lösungen ist dies wohl nichts *g*.
Jemand eine Idee?
Bootloader -> MinimalLinux -> Bootloader2 -> ProduktivLinux
Gruß
rob
IP-faehiger kvm dran und ein boot-medium erreichbar haben (usb, cdrom, eth) reicht.
wenn man für 65 Euro ein Linksys WRT54g erwirbt und dort eigene Kernel ausprobiert ist ein kvm nicht nur _deutlich_ teurer, sondern hift auch nichts, wenn etwas schief geht. Aber auch für andere Fälle dürfte kexec ein _nettes_ tool sein.
rob
"wenn man für 65 Euro ein Linksys WRT54g erwirbt"
spielen solche dinge sowieso keine rolle, da home-betrieb.
"und dort eigene Kernel ausprobiert"
beim 'ausprobieren' hat man lokalen zugriff auf das geraet. abgesehen davon sollte man mit solchen dingern nicht rumspielen, wenn man a) darauf angewiesen ist, dass sie hohe verfuegbarkeit haben und b) wenn man keine ahnung hat. ergo ergibt sich keine situation, wo das noetig ist (ganz allgemein festgehalten - nicht auf jemand bestimmten bezogen).
</meine meinung>
ich hätte Dir allgemeiner Antworten sollen:
"JUST FOR FUN"
Außerdem ist b) Deiner Meinung ein Dogma, welches nicht zur Verbreitung von Wissen, Erfahrung und allgemein Linux beiträgt.
Grub läuft nicht überall und hat kein SSH2. Der WRT54g ist ein Beispiel für ein Flashvorgang, bei dem ein Fehler zu einem unbenutzbarer Kiste führen kann (Je nach Modell und Erfahrung). Wie will man für embedded Geräte entwickeln oder hacken? Xen läuft da nicht und Hardwareemulatoren??? Hat man ersteinmal einen simplen Kernel mit kexec erfolgreich geflasht, kann man sich ohne großen Zeitverlust und ärger weiter "vortasten".
Auch gibt es Einsatzideen und Möglichkeiten, bei dem man kein kvm einsetzen kann/will (Wetterstation, Raumsonde,.....) so daß Deine Reaktion fast nahelegt, das Du betroffen wärest, wenn man weniger kvms kaufen würde.
Für Interessierte empfehle ich diesen IBM Artikel:
http://www-106.ibm.com/developerworks/linux/library/l-kexec.html
Wichtigeste news:
"Kexec is currently available on the x86 32-bit platform only."
Hmm IMHO wären gerade nicht x86 - die embeddet Plattformen interessant - was nicht ist könnte noch werden.
Da der neue Kernel komplett in das Ram geladen wird, und dann gestartet wird könnte
man mit einem kexec-Kernel ein System von einem FS booten, das der orginale Bootloader nicht mounten kann - USB oder gar übers Netzt. Wenn man Systemen 1-4 MB Flash onboard spendieren würde bräuchte man zukünftig nur eine Internetverbindung um den
aktuellsten Installer seiner Wunschdistribution starten (Natürlich über eine Sichere Verbindung und einer Signierungskeyüberprüfung). Usw.
IMHO hat kexec hat eine Menge Potential und ist eine Ergänzung (in andere Richtungen) zu den Möglichkeiten von XEN.
Gruß
rob
Ansonsten kauf dir halt 2, einen zum Testen neuer Kernel, der an deinem Schreibtisch steht und den du jederzeit über boot_wait tftp neu flashen kannst wenn nix mehr geht, und einen den du auf's Hausdach montierst (oder wohin auch immer) und nur mit getesteter Firmware flashst.
Grüße,
Gunter
1. einen neuen Kernel von der Festplatte lädt
2. ihn in den RAM kopiert
3. das System mit diesem Kernel neustartet
Wäre also das was du willst. Wichtig ist noch, dass dabei selbstverständlich das laufende System (inklusive aller Prozesse) stirbt.
das alle alten Prozesse dabei sterben ist bei z.B. 16 MB Ram Systemen _kein_ Nachteil,
sondern sehr erwünscht. ;)
kexec ist der Patch, den ich gesucht habe. Habe eben durch andere
Postings einwenig gesucht und war auch auf kexec gestoßen.
Ohne Wertung einpaar Treffer:
http://lwn.net/Articles/15468/
"Kexec is a patch to the Linux kernel that
allows you to boot directly to a new kernel
from the currently running one. Kexec skips
the entire bootloader stage and directly jumps
into the kernel that the user want to boot to.
There is no hardware reset, no firmware
operation, and no bootloader involved. The
weakest link in the boot sequence, the
firmware, is completely avoided. The big gain
from this feature is that system reboots are now
extremely fast."
http://www.techmount.com/index.php/
20040505/reboot-linux-faster-using-kexec/
Hört sich gut an - zufällig jemand hier, der schomal kexec genutzt hat?
Gibt es irgendwelche Einschränkungen z.B. auf Plattform, oder kann man xexec überall da
nutzen, wo auch Linux läuft?
Werde ich gleich nach der Klausurzeit ausprobieren ;)
Danke und schönes WE,
rob
Gibt es eigendlich schon ein ISO mit verschiedene Kernel mit kexec? Ganz schnell von Kernel zu Kernel springen?
Gruß
rob
Grüße
- Grub mit einer seriellen Console und einem alten Palm (die benutzung der großen Tastatur wäre warscheinlich dann noch zu hacken...)
http://www.gnu.org/software/grub/manual/grub.html#Serial%20terminal
- Bootdiskette für eins der OS
- Kexec
--gibt es einen Bootloader mit Sprachausgabe?? ;)
Gruß rob
Eventuell läßt sich ja auch der Turbo-Button umfunktionieren - oder ich lege statt einer /boot - doch eine DOS - Partition an. Dann würde ich von Win2k auf Win98 umsteigen - brauch ich ja eh nicht sehr häufig.
Nachdem meine Videograbberkarte jetzt hervorragend unter Linux läuft, fliegt Windows evtl. auch komplett runter - muß mal sehen. Ist eigentlich nur noch Fritz als Windows-Programm wichtig.
Grüßings
http://www.kernel.org/kdist/finger_banner
(nur so als tip)
es gab ja in den letzten Monaten viele Diskussionen darüber, wie Xen am besten implementiert werden soll. Momentan ist Xen eine eigene Architektur in /arch/xen, wobei — ähnlich wie bei x86_64 — diverse Dateien aus /arch/i386 mitbenutzt werden.
Einige Entwickler fanden, dass Xen nicht verschieden genug von i386 sei, um eine eigene Architektur zu sein und es in i386 integriert werden solle, bevor es in Andrew Mortons Kernel aufgenommen wird. Andere meinten, man solle es erst in Andrew Mortons Kernel aufnehmen und dann nach und nach in i386 integrieren. In beiden Fällen war die Begründung, dass es derzeit eine Menge doppelten Code in i386 und Xen gibt und doppelter Code immer Wartungsprobleme mit sich bringt.
Wieder andere Entwickler wiesen darauf hin, dass bereits an einer Portierung von Xen für x86_64 gearbeitet wird und eine für PowerPC in Planung sei und wenn man dann diese Portierungen wiederum in x86_64 und ppc integrierte, hätte man wiederum den Xen-spezifischen Code doppelt oder gar dreifach. Also sollte man Xen aufsplitten und den generischen Code in /arch/xen und den plattformspezifischen Code in z.B. /arch/i386/xen unterbringen.
Die ganz ambitionierten weisen dann noch darauf hin, dass es bereits zwei VM-Architekturen in Linux Torvalds "Mainline"-Kernel gibt (s390 und ppc64) und man bevor eine dritte hinzugefügt wird, erstmal die drei zu einer generischen VM-Architektur vereinheitlichen sollte.
Die Frage ist jetzt: weiß jemand, für welches Modell man sich jetzt entschieden hat?
jwm