lkml.org 
[lkml]   [1998]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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....

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:1.168 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site