Messages in this thread | | | Date | Wed, 9 Jun 1999 14:39:23 +1000 | From | CaT <> | Subject | Re: Devfs, was Re: Migrating to larger numbers |
| |
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/
| |