[every your question comes as one long like here]
В Птн, 10.05.2002, в 21:31, Marton Kadar написал:
> Hello all,
>
> I use kernel 2.4.9 with devfs support, and installed devfsd too.
> The fs is not mounted automatically, nor do I use the "only" option. I mount
> the fs manually, often not on /dev, and experiment with things before I
> finally dump the old /dev directory. I like the idea of devfs very much, but
> still have a few questions:
>
> I have read in the FAQ the following sentence:
> "Also, because the devfs namespace exists without any devfs mounts, you can
> easily mount the root filesystem by referring to an entry in the devfs
> namespace."
>
> 1. I find it a little confusing or at least not conceptually clear that I
> have to pass "root=/dev/ide/..." to the kernel even while the fs is not
> mounted anywhere, and that /proc/mounts will show the root device mounted on
> /dev/ide/... even though I might later mount the devfs to say /mnt/dev or to
> several mount points, all different from /dev, if I please. In fact the
> current setup suggests that the kernel mounts one single device node of the
> devfs tree but nothing else. This is kind of a chicken and egg problem: to be
> able to refer to the (root) device by node name (in order to mount it) you
> need the node, for the node to exist, however, you need the filesystem, which
> in turn needs the root device to be mounted. I would find it lots cleaner to
> be able to say "root=ide/..." or "root_device=ide/..." instead.
>
> 2. Can I persuade the kernel to mount the fs at boot time to something other
> than /dev?
>
> 3. Not strictly confined to devfs, but also to modutils, is this: If I
> compile my kernel with some devfs-aware modules, then basically the module
> (say sg.o) contains the information, what device node(s) it will implement
> (through devfs_register(), which I cannot change without kernel patching).
> Still I have to manually specify through a devfsd LOOKUP event and a
> modules.conf alias, that a request for module /dev/scsi/.../generic will
> really mean a request for module sg, although there is not a lot of other
> choices. I would appreciate comments on this apparent duplication.
>
There is no redundancy. devfs is passive. It reflects exactly the loaded
drivers (actually I never liked the name. driverfs would be more close
to reality). You still need to load corresponding drivers.
Without devfs you have special with major so when kernel tries open
unknown (a.k.a. unregistered) major number it generates modprobe for
(char|block)-major-N. You do not normally see it because modutils handle
most standard aliases.
With devfs you do not have any file (and you do not have static major
numbers as well) so you have to load drivers basing on names.
In the sense it looks redundant, I agree. It could be hidden if there
were standard way to export names handled by drivers; then modutils
could collect them into table (just like what happens with PCI or USB)
so the whole would work semi-transparent.
> 4. Is devfsd the only designed way to autoload devfs-aware modules? As I
> understand it is the kernel-resident devfs code that detects the lookup
> event, and devfsd only knows about it via the .devfsd communication channel,
> so requesting the module would be simple without devfsd running, unless we
> want to carry out some special action.
>
You need something that receives LOOKUP event and decides what module to
load. If you do not like name "devfsd" call it differently but it still
has to to the same.
As far as first two questions I am interested as well.
-andrej
|