Re: Devfs, was Re: Migrating to larger numbers
CaT (cat@zip.com.au)
Wed, 9 Jun 1999 20:31:44 +1000
On Wed, Jun 09, 1999 at 12:25:01PM +0100, DAVID BALAZIC wrote:
> >From: Richard Gooch <rgooch@atnf.csiro.au>
> >
> >DAVID BALAZIC writes:
> >> Richard Gooch (rgooch@atnf.csiro.au) wrote :
> >>
> >> > cat@zip.com.au writes:
> >> >
> >> > > 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.
> >>
> >> But what is devices appear after boot ?
> >> Like user plugs in a new CD drive and /dev/some-bus/cd/cd3 appears,
> >> but who will create /dev/cd/something/cd3 ?
> >
> >Think about it. You don't create /dev/cd/something/cd3. What you do is
> >create /dev/cd/ide which points to /dev/ide/cd. Simple.
> >Thus /dev/cd/ide/blah points to /dev/ide/cd/blah.
>
> Aha , bit what about /dev/super-ide , /dev/esdi/ , /dev/firewire,
> /dev/fibre-channel and such appear ?
> I'm pushing it , OK ...
I suppose I'm missing something here but why would this be a problem?
Say you have:
/dev/firewire/cd/*
/dev/ide/cd/*
Then you have:
/dev/cd/ide -> ../ide/cd
/dev/cd/firewire -> ../ide/cd
Or am I missing something?
--
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/