Theodore Y. Ts'o writes:
> Date: Thu, 20 Apr 2000 11:15:05 +0200 (MEST)
> From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
>
> Building on this, shouldn't devfs (which then shouldn't be called
> devfs) just publish a list of attached devices, node numbers and
> "recommended permissions"?
>
> From that you can write a simple bash script that will read all the
> devices and create nodes for them.
>
> After 30 more minutes, the number of feature requests for this program
> is enough to warrant a C implementation. Fine.
>
> As we've come to the conclusion that a devfsd is a necessity, the
> "extra" deamon cannot be considered a problem. Moreover, this is just
> a "at boot time" thing that needs to run. You get back your process
> slot once it is done.
>
> Looking at it this way, to me feels like everything suddenly clicks
> into place.
>
> At first, the kernel publishing the attached devices sounds like
> a good idea. And a "filesystem" sounds like the obviously correct
> way to export that info. However, the permissions issue
> complicates it to the point where the "publish as a filesystem"
> policy should be reconsidered.
Actually, the recent COPY action I added to devfsd makes this clean
and easy to manage.
> That's basically right (as far as I'm concerned), although the
> daemon does have to be continuously running, to deal with hot-swap
> devices. It's the design I've always thought was the right one.
Agreed. The daemon should always be running
> People kept on saying that using a filesystem was the right
> approach, because the using a user-mode daemon "was too
> complicated", and then when people started pointing out
> shortcomings, the answer was "use devfsd".
That's not really how it happened, though. I didn't argue against a
daemon per se, I was arguing against have a daemon populate /dev.
I was also arguing against the proposal to scavenge procfs and boot
messages to figure out the devices available. That wouldn't work
anyway, because there isn't enough information published.
So a new kernel API was needed to export this information to
user-space, and a FS was the natural way to do it. It's easy to
represent the topology of the underlying hardware.
A further advantage of the FS approach is that you can mount it over
/dev if you so desire: that's quite a legitimate thing to want to do.
Devfsd didn't start life as a way of overcoming the sortcomings of
devfs, it was created to do new things (things not possible with a
disc-based /dev). Only recently have I added actions so that people
can manage persistence in the conventional way, if that's what they
really want.
The devfsd protocol gives you an awful lot of control over /dev that
you can't get with a disc-based /dev. And that control allows people
to do new, interesting and useful things. I expect a lot more ideas on
how to take advantage of this will be generated as people understand
what devfs+devfsd provides.
> But after kludge after kludge started getting poured into devfsd (or
> into the VFS, which was Richard Gooch's latest attempt to work
> around this problem) to deal with the fact that there really is
> persistent state in /dev that needs to survive device insertion and
> removal, not to mention reboots ---- you have to start wondering
> which approach is really the more complicated one.
Devfsd gave a new (better, for some uses) way of managing persistence
right from the start. That wasn't a kludge. Just because it was
different from the conventional method, doesn't make it a kludge or
the wrong thing to do. I wrote that new persistence method because I
*wanted* that particular method. It was more useful to me than the old
method.
But once I had written the new method, it became trivial to add a
method which more closely resembled the conventional method (a point I
made a long time ago, although I've only just recently bothered to
implement a convenient interface).
I really take offence to the suggestion that "kludge after kludge
started getting poured into devfsd". I added features that were useful
and were not possible with a disc-based /dev. I wasn't working around
limitations in devfs, I was doing new things. Cool stuff.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:10 EST