Linux-kernel mailing list archive 1999-23,: Re: Devfs, was Re: Migrating to larger numbers

# Re: Devfs, was Re: Migrating to larger numbers

Richard Gooch (rgooch@atnf.csiro.au)
Wed, 9 Jun 1999 19:55:38 +1000

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Mailing lists: "Re: Unresolved symbol isa_dma_bridge_buggy in Linux 2.3.5 w/"
- Previous message: david parsons: "Re: Devfs, was Re: Migrating to larger numbers"

Matthew Kirkwood writes:
> On Wed, 9 Jun 1999, Richard Gooch wrote:
>
> > > 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).
>
> Not only don't you need to modify devfs for this, you don't even
> need to _use_ it :)

You've seem to have missed the earlier part of the conversation. What
devfs allows, and what can't be done in user space, is:
opendir ("/dev/ide/cd");
loop;

and be assured that:
- /dev/ide/cd is populated with device nodes for any IDE CD-ROMs you
have
- /dev/ide/cd contains *only* IDE CD-ROM device nodes.

Thus each and every entry (except "." and "..") is an IDE CD-ROM. No
more, no less.

Regards,

Richard....

-
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/

- Next message: Mailing lists: "Re: Unresolved symbol isa_dma_bridge_buggy in Linux 2.3.5 w/"
- Previous message: david parsons: "Re: Devfs, was Re: Migrating to larger numbers"