Messages in this thread | | | Date | Thu, 8 Jan 1998 12:27:36 +1100 | From | Richard Gooch <> | Subject | Re: PROPOSAL: /proc/dev |
| |
ketil@ii.uib.no writes: > o.r.c@p.e.l.l.p.o.r.t.l.a.n.d.o.r.u.s (david parsons) writes: > > > I want a devfs so that I can have the kernel tell the outside world what > > devices exist. For things like ptys, I don't particularly care about > > a devfs -- the existing scheme is sufficient -- but for serial, > > parallel, ide, and scsi devices I'd much rather mount a magic > > filesystem instead of having to root through /proc/kmsg to find out > > Just a thought as to the configurability of devfs - ya know, number of > ptys, ownership, permissions, multiple (chroot) /dev directories etc - > couldn't the devfs be an overlay (a la unionfs) on top of a regular > /dev directory?
You still need to stuff around allocating major&minor numbers. Part of the motivation for this is to avoid that.
> a) devfs can copy permissions and stuff from the underlying directory > b) you could (conceivably?) mknod and chmod "through" the devfs > c) you could boot a non-devfs kernel and expect it to work > d) each device (driver) could decide what devices to expose from the > underlying directory - e.g. ptys would just pass through, disks would > only show what actually exists and provide rw------ devices for > volumes that don't exist "below", other devices might choose to ignore > it entirely, etc > e) you wouldn't depend on messy config files in /etc or anywhere to get > stuff working.
The semantics of adding entries (what happens if overlayfs is not mounted yet and a driver "exposes" (installs) the /dev entries?) are sufficiently complicated that you need a special-purpose devfs, IMHO.
Regards,
Richard....
| |