Hallo, Am Mon, 05 Jan 2004, Adalbert Michelic schrieb:
* On Mon, 05 Jan 2004 at 5:00 +0100, David Haller wrote:
IMO ist ein "load after boot" (wie es korrekter heissen muesste) generell ueberfluessig und ein eindeutiges Zeichen dafuer, dass die modules.conf nicht korrekt bzw. unvollstaendig ist.[1]
Generalisierungen sind generell flhsch *eg*
Generell ja. *g*
IMO ist das schlicht die _zwangslaeufige_ logische Schlussfolgerung aus dem Konzept der Module.
Nein, warum?
Darum. *eg* [Argumente findest du unten und in anderen Mails von mir, wenn du mich ganz lieb bittest kann ich die auch nochmal explizit auffuehren]
Ebenso ergibt sich das mit der (nicht zu verwendenden) initrd fuer _eigene_ Kernels, die nur auf einer Maschine laufen sollen,
Probierst Du bitte mal / mittels LVM zu verwalten oder auch blos das /-Volume zu verschlüsseln und davon auch zu booten? Ohne initrd.
Geht nicht. Zumindest wenn /lib/modules/`uname -r` auf / also auf dem LVM residiert. LVM hatte ich nur mal kurz im Test. Aber bei Bedarf, d.h. bei Zugriff, sollte a) das Modul, da unter /lib/ auf / gespeichert eh fest in den Kernel bzw. in die initrd muessen, und b) das "laden bei Bedarf" ueber einen korrekten Eintrag in der modules.conf zu erschlagen sein. Ein _explizites_ haendisches laden per "modprobe lvm" (oder wie auch immer) in irgendeinem der bootscripte ist _NICHT NOETIG_. Fuer's verschluesseln gilt analoges. Dein Argument das noch uebrig bleibt ist? Kann sein, dass ich missverstaendlich formuliert hatte, den Teil mit der Einschraenkung hast du ja aber geloescht. Ich sach's nochmal deutlicher: Wer von LVM / ner verschluesselten Partition booten will, der muss lvm/loop (+cryptozeug) a) fest in den Kernel, oder b) in die initrd packen Dass b) bei nem eigenen Kernel _fuer eine Maschine_ wenig sinnvoll ist schrieb ich ja schon ;) Aber das ist ja sowieso nur das gleiche Spielchen wie mit ner SCSI-HDD an ${FOO} SCSI-Controller, der via Modul ${foo} angesprochen wird. Das Modul muss a) fest in den Kernel, oder b) in die initrd. etc. bla. s.o.
-dn'*gespannt*'h, den das echt mal interessieren wuerde, ob's ein Modul gibt, das nicht in die initrd / fest in den Kernel muss, aber dennoch schon (moeglichst frueh?) beim booten geladen werden _muss_... Falls es so ein Modul geben sollte bin ich aber sowieso der Meinung, dass das dem jew. Autor erstmal ordentlich um die Ohren gehauen werden sollte, da es das Modul-Konzept ad absurdum fuehrt, dann soll's lieber nicht als Modul kompilierbar sein (und dann latuernich auch fest im Kernel laufen)...
Framebuffer-Treiber, der auch wieder mal wieder raus soll, weil er sich u.U. mit was anderem in die Haare kriegt?
Ok, das koennte (in der Praxis(!)) eine Ausnahme sein, ja. Gegen solche begruendeten Ausnahmen hab ich auch nix. matroxfb ist aber z.B. sauber programmiert. Da greift also der Nachsatz: wenn z.B. rivafb oder sonstwas so schlecht ist, dass es Konflikte gibt, dann sollte man den Treiber den Entwicklern um die Ohren hauen, oder den Entwicklern dessen, mit dem sich der Treiber in die Haare kriegt. Das hat also nix mit dem Modulkonzept per se zu tun. Achso, fuer "Kernel-" und "Treiber-" Entwickler gelten sowieso andere Regeln, die wollen natuerlich alles ent- und neuladen koennen. Sowas sollte dann aber nicht in "stable"-Kernels auftauchen. Ich habe absolut nix dagegen, dass man fuer Entwicklerkernel auch mal uebelste Hacks und "dirty tricks" anwendet etc. pp.... Das ist aber eben ein anderes Thema.
Oder andere Sachen, die nach dem Booten verfügbar sein sollen, später aber u.U. wieder raus sollen?
Dafuer sorgt modprobe. Ich kann problemlos z.B. per 'mount /cdrom' das automatische laden von 'sr_mod + cdrom + scsi_mod + ide-scsi' anstossen, und nach nem 'umount /cdrom' problemlos die (noch nicht automatisch entladenen) Module per 'modprobe sr_mod cdrom ide-scsi scsi_mod' auch wieder entladen... Wo also ist das Problem? -dnh -- 140: Zufall Zufall ist ein Umstand, den weder der Schuldner noch der Gläubiger zu vertreten hat. (Jurist Wolfgang Kopp)