Re: Devfs, was Re: Migrating to larger numbers
CaT (cat@zip.com.au)
Wed, 9 Jun 1999 15:11:42 +1000
On Wed, Jun 09, 1999 at 03:04:43PM +1000, Richard Gooch wrote:
> 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.
Ok. Fair enough. :)
Now I'm really stepping into dark and murky waters (for me :). How would
hot swappable/removable devices (zip/jaz/120mb disks, removable HDs) get
handled in this scheme.
For example: Zip disks.
Amiga zip disks are hd?1 (on an ide interface) while msdos ones are hd?4.
I might also wish to create a zip disk with 2 partitions (for whatever
reason).
How would this be handled?
I suppose a question in hiding here is how partitions on HDs are handled. Is
the mapping something like:
/dev/hda1 -> /dev/ide/hd/a1
or somesuch?
--
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/