On Mon, 16 Jul 2001, Richard Gooch wrote:
> [...]
> > But I still don't have my /dev/hdb! Well, it appears there as soon
> > as ide-cd is loaded, but I don't know how to make it work "by lookup".
> > Yes I can do `alias /dev/hdb ide-cd', but this assumes that /dev/hdb
> > is always a CD-ROM. The problem is that there is no magical device
> > like the old /dev/hdb, referring to "whatever sitting at the primary
> > slave IDE".
>
> Whatever /dev/hdb is will be host-dependent, and thus must be left to
> your personalised configuration files.
Well, right, an "unknown" IDE device is of almost no use. Maybe only
hdparm can reasonably deal with such a beast. And if this is a devfs
issue at all, it's not the same device as "cdrom" or "disc". It's
like "ttyS#" versus "ppp#". But an "IDE controller" device is
probably not a thing that anyone wants to implement.
> [...]
> > 1) The "probeall" lines in modules.devfsd are bad - because the effect
> > is inpredictable. More generally, loading modules by lookup should not
> > load anything beyond the module providing the referenced node.
>
> There isn't a way to do that. A single driver can support more than
> once device.
I did not say "nothing except this node". I mean "a minimal subsystem in
which this node exists". It's not a problem that one driver may add many
files to /dev. The problem is when different drivers "provide" the same
name - like /dev/ide or /dev/cdroms, and do not "own" it. Then one cannot
rely on autoloading by this name - except the limited "make sure that
at least one cdrom driver is loaded" (probe, but not all).
In fact, it's just that more aliases are needed, like
alias /dev/cdroms/cdrom? /dev/cdroms
Then /dev/cdroms/cdrom1 works even if /dev/cdroms/cdrom0 already exists.
I still don't like the "probeall" thing for probing too much (e.g.
ZIP drive without media) but it's only a configuration option after all.
BTW, it seems more logical for /dev/cdroms etc to always exist.
There is a "driver" (inside devfs) whose job is to register cdrom
devices. It "owns" the directory /dev/cdroms. Why not create this
directory as soon as this "driver" is initialized? It would show
the existence of the "registration system", not the existence of cdroms.
And this subsystem could be optional, or even a module (if you want
access via /dev/XXXs - load it, if not - why waste memory).
And one more question/suggestion: why /dev/scsi and /dev/ide aren't like
/dev/discs and /dev/cdroms? The numbering issues would go away if
/dev/scsi/host# was a link to a driver-specific name, say
/dev/scsi/aha1542/host0, or to /dev/all-drivers/ppa/host0.
Or even /dev/scsi/host#/.../lun# might be a link to
/dev/somewhere/ppa/parport0/disc0 if the ppa driver chooses so.
Yet another bloat?
> [...]
> > 3) If a driver can load modules itself, devfs should cooperate.
> > Not everything can be done via devfsd.
>
> Devfsd is great: it can come with a default configration to work
> correctly on most systems, and it can be configured by the sysadmin as
> required. We don't want the kernel hard-wiring stuff.
Oh yes. The driver shows everything in /proc. A userspace program
can scan /proc/ide and figure out which module is needed for
the "unknown piece of hardware attached to that IDE interface".
No real need for this stuff in the kernel.
> > P.S. It would be nice to mention in the FAQ that non-devfs modules
> > do not work with devfs kernels.
>
> It's the same as many, many other CONFIG options. Change the
> configuration, and modules are no longer compatible. This a basic FAQ
> entry and belongs elsewere.
Sorry, this was new to me. Most options are mere add-ons,
and things like SMP/non-SMP are "obvious". Even procfs only adds
code to modules - they probably would work if compiled without it.
But non-devfs modules break badly under a devfs kernel.
Regards,
Sergei
|