Re: Devfs, was Re: Migrating to larger numbers
CaT (cat@zip.com.au)
Wed, 9 Jun 1999 14:39:23 +1000
On Wed, Jun 09, 1999 at 02:34:59PM +1000, Richard Gooch wrote:
> cat@zip.com.au writes:
> > On Wed, Jun 09, 1999 at 02:22:16PM +1000, Richard Gooch wrote:
> > > It is the right way. The concept is still valid. Just extend my
> > > example code. It wasn't meant to be complete, just enough to convey
> > > the idea. Did I really have to spell that out?
> > >
> > > Also, I expect that a PCMCIA CD-ROM will really be an IDE CD-ROM. A
> > > parport CD-ROM will probably be either IDE or SCSI.
> >
> > Out of curiosity, why not also have the reverse? since it's a virtual
> > device it can be done automatically and then if you want a cd you can
> > open /dev/cd/ (or something similar) and go through anything in there.
> > That way you don't have to guess at the possible ways of connecting a
> > cd to the machine when you want to find them all.
>
> You can't directly because they come from different drivers. This
> scheme works because each of the CD-ROM drivers has it's own
> directory. To do what you want would require something clever with
> devfsd.
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?
--
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/