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/