Re: Eintrag in modprobe.conf oder modprobe.d

From: Philipp Matthias Hahn <pmhahn_at_titan.lahn.de>
Date: Wed, 8 Nov 2006 15:20:27 +0100

Moin1

On Wed, Nov 08, 2006 at 09:23:49AM +0100, Christoph Sandhaus wrote:
> Mir drängt sich folgender Verdacht auf:
> ich kann da konfigurieren wie ich lustig bin, da wird nix passieren, weil
> sshfs beim Mountversuch die Existenz von /dev/fuse prüft. Ist das Device
> nicht da, macht sshfs nicht weiter. Möglicherweise KOMMT es erst gar nicht so
> weit, daß der Kernel überhaupt um das Nachladen irgendeins Moduls- mit
> welchem char-major auch immer - gebeten wird.

Eine Henne-Ei-Geschichte:

Der Linux-Kernel besitzt zwei große Häuser, in dem er untergebracht ist:
Das "block"-Haus und das "character"-Haus. Jedes Haus hat mehrere
Stockwerke (major-Nummer) und auf jeder etage viele Türen, die mit der
(minor)-Nummer durchgezählt werden. Will man mit dem Kernel reden, muß
man die passenden Tür finden und öffnen.

Leider verstehen die normalen Anwender nicht von diesem Major-Minor-
System, sondern kennen nur solch schöne Namen wie "/dev/sda1" oder
"/dev/fuse". Deshalb gibt es einen Hausmeister mit einem
(Datei-)verzeichnis, der berechtigten Personen darüber auskunft gibt,
hinter welcher Tür sich den der gewünschte Gesprächsparter des Kernels
befindet.

Der alte Hausmeister hatte eine statische Liste, die sich so gut wie nie
verändert hat. Diese Liste war oft veraltet und hatte auch viele
Einträge für Türen, hinter denen sich schon lange nichts mehr befand
(/dev/xda0, /dev/sunmouse) oder nicht immer jemand zu Hause war
(/dev/usb/input1, /dev/rfcomm33). So passierte es des öfteren, das ein
Anwender voller Erwartung vo einer Tür stand, die er erst mühsam suchen
musste, nur um dann festzustellen, daß die Tür nur aufgemalt war oder
daß sich hinter der Tür gar kein Zimmer befand (ENODEV).

Manche dieser Türen waren aber auch der Natur, daß sie zunächst wie
aufgemalt aussahen, aber eine Klingel besaßen: Beim Öffnen wurde flucks
der Hausmeister geweckt, der in windeseile die aufgemalte Tür durch eine
echte Tür ersetzte (alias char-major-10-229 fuse), so daß der Anwender
diese ganz normal öffnen konnte.

Irgendwann verstab der alte Hausmeister an Fettleibigkeit (Filesystem
/dev/ full) und wurde durch einen neunen Hausmeister mit dem Namen
"udev" ersetzt. Als erste Tätigkeit vernichtete er das alte Verzeichnis
und führte ein Hauspostsystem Namens "Hotplug" ein. Das hatte noch
einige Macken, also wurde es kurzerhand durch "Netlink" abgelöst.
Darüber konnten die Bewohner der Kernel-Häuser dem Hausmeister
mitteilen, sobald irgendwo neue Zimmer entstanden (Haus "char", Stock
224, Zimmer 42) oder abgerissen wurden. Anhand dieser Nachrichten
erstellte der neue Hausmeister nun jeden Tag ein aktuelles Verzeichnis
aller Zimmer (/dev/usb/event42), die zu jedem zeitpunkt gerade vorhanden
waren.

Immerhin gab es damit jetzt auch die Möglichkeit, Personen, die von Zeit
zu Zeit die Zimmer wechselten, immer mit dem gleichen Namen
(/dev/dvd_blau_oben) einzutragen. Zwar änderte sich immer mal wieder
deren Zimmernummer, aber das war egal, weil sie ja im Verzeichnis
standen (auch wenn es für Fremdlinge jetzt schwerer war
herauszubekommen, unter welchem Namen eine bekannte Person zu finden
ist). Waren sie aber gerade nicht da, standen sie auch nicht im
Verzeichnis und hatten auch keine aufgemalte Tür mehr. Damit hatten sie
aber auch keine feste Klingel mehr, mit der man sie hätte automatisch
rufen können.

Für viele der Kernel-Bewohner war dies auch unnötig, denn auf ihre
Existenz konnte aus verräterischen Spuren geschlossen werden: Alte
Schatzkarten (BIOS-Tabellen, PCI-Discovery, SCSI-Scan) verrieten den Weg
zu ihnen, so daß kleine Gehilfen zu jedem Tagesanfang losgeschickt
wurden, um nachzusehen, welche Bewohner es in den Häusern gab. So kam es
dann auch, daß sich hinter der PCI-Tür eine SCSI-Gang auftat, der zu
mehreren SCSI-Platten führte, von wo aus man Partitionen und ähnliche
Wiedrigkeiten fand.

Manch andere Bewohner hatten aber die unangenehme Eigenschaft, Nachts
einzuschlafen und am nächsten Morgen nicht selbständig aufzuwachen. Da
ihre Türen in Vergessenheit geraten waren, blieb das auch so, außer der
allmächtige Übervater (root) machte sich auf die Suche nach ihnen und
weckte sie gewaltsam auf (modprobe fuse). Erst dann wurden sie aktiv,
meldeten sich per Hauspost wieder beim Hausmeister an und konnten von
dann auch wieder von normalen Anwendern unser solch illustren Namen wie
/dev/fuse gefunden werden.

(Jetzt erstmal Webung)

fusermount muß mit dem Kernel kommunizieren und braucht dazu das Zimmer
/dev/fuse. Für diese Zuordnung von Namen zu Mahor-Minor-Nummer gibt es
verschiedene Möglichkeiten:
Für Geräte, die eine feste Major-Minor-Nummer haben, kannst du per
Hand per mknod einen festen Eintrag in /dev/ erzeugen. Beim Öffnen kann
dann der Kernel über einen alias-Eintrag in der /etc/modprobe ggf. das
Modul nachladen.
Wenn du udev einsetzt, mußt du udev dazu überreden, dir eine solche
aufgemalte Tür einzurichten. Wie das geht, hängt ein bisschen von deiner
verwendeten Distribution ab; unter Debian gibt es sowas wie
/etc/udev/links.conf.
Wenn fuse jedesmal eine andere Major-Minor-Nummer bekommt, hast du
bezüglich dieser Vorgehensweise (automatisches Laden beim Öffnen)
verloren: Hinter der aufgemalte Tür ist nicht immer ein Zimmer oder auch
mal was ganz anderes, als der Name eigentlich vermuten lassen würde.

Stattdessen mußt du das fuse-Modul explizit per Hand laden. Wie das
geht, hängt ein bisschen von deiner verwendeten Distribution ab; unter
Debian gibt es sowas wie /etc/modules.
Durch das Laden per modprobe erhält dann udev eine Nachricht mit der
Major-Minor-Nummer und kann dadurch dann den Eintrag /dev/fuse anhand
der Regeln in /etc/udev/rules.d/ erzeugen.
Verwendest du kein udev, mußt du dir die Informationen selber per Hand
aus /proc/devices und ggf. /proc/misc oder dmesg zusammensuchen und den
Device-Eintrag selber per mknod anlegen.

BYtE
Philipp

-- 
  / /  (_)__  __ ____  __ Philipp Hahn
 / /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\ pmhahn_at_titan.lahn.de
Received on Wed Nov 08 2006 - 15:20:27 CET

This archive was generated by hypermail 2.2.0 : Wed Nov 08 2006 - 15:20:45 CET