Re: Devfs, was Re: Migrating to larger numbers
CaT (cat@zip.com.au)
Wed, 9 Jun 1999 14:58:47 +1000
On Wed, Jun 09, 1999 at 02:47:56PM +1000, Richard Gooch wrote:
> cat@zip.com.au writes:
> > Hmmm. I'm not sure why. Currently (from what I've seen in this
> > thread) you have a scheme of /dev/<interface>/<device>/*. What I'm
> > saying is that you can also have say /dev/<device>/<interface> and
> > let programs cycle through that. Those that are interested in seeing
> > what's on an interface look in /dev/<interface>. Those who are
> > looking for a device go for /dev/<device>. The driver just reports
> > its stuff in two places. The difference is the code should really be
> > almost nonexistant, no? Or am I getting something phenomally wrong?
>
> OK, I misunderstood you. It seemed to me that you were proposing that
> *all* CD-ROM entries would appear in a single directory (no
> sub-directories). That would be tricky. But the scheme you outline
> would be pretty easy. You don't even need to modify devfs to support
> this. All you need to do is set up some symlinks (from user space).
True I suppose. But from what I see at least one of the reasons for devfs
is that the user doesn't need to keep maintaining /dev. Having to put the
links in userself kinda defeats that. You could have devfsd (something you
mentioned I think) do it or, alternatively, just add a small mod to devfs
itself and forget about having to support it externally. this latter option
would possibly be more reliable too as it would permit both entries to be
updated simultaneously rather then have one updated, wait for devfsd to
catch it and so on.
--
CaT (cat@zip.com.au) URL: http://zipper.zip.com.au/dev/null
-
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/