Messages in this thread | | | Date | Wed, 9 Jun 1999 15:04:43 +1000 | From | Richard Gooch <> | Subject | Re: Devfs, was Re: Migrating to larger numbers |
| |
cat@zip.com.au writes: > 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.
I'm not suggesting that the user has to worry about this. This is done in the boot scripts or in devfsd. I just don't thing that this belongs in devfs (i.e. the kernel) itself. There's no need. Creating the symlinks only needs to be done once at boot time.
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/
| |