> On Fri, 8 Oct 1999, Stephen Frost wrote:
> > On Fri, 8 Oct 1999, Dan Hollis wrote:
> > > On Fri, 8 Oct 1999, Stephen Frost wrote:
> > > > > Im a devfs advocate but I agree the symlink design is bad.
> > > > > Would an overmountable devfs address most of the arguments against it?
> > > > Not sure... Could you elaborate on what you mean by 'overmountable'?
> > > I guess the better term is "Union fs".
> > The idea being that devfs and /dev (on the disk) are one and the same
> > and the kernel is happily off making changes to files on the disk when a device
> > is added or removed? That and devfs catches the 'open' call to determine what
> > device to talk to?
>
> Sort of. devfs wouldnt actually make any files on disk -- overmounting
> would only be used for permissions persistence. That is, any file which
> devfs creates is virtual *unless* someone changes permissions on it. Then
> its written to disk. devfs would use the existing permissions if the file
> already exists on disk when devfs is mounted.
>
> This way, if the end user never changes permissions, nothing ever touches
> the disk. Think read-only filesystems, or filesystems without 'device
> file' semantics (ntfs, etc.)
>
> The alternative way would be to use the "devices.permissions" file as I
> stated in another email. When mounting /dev the kernel opens
> /dev/devices.permissions before placing the file over the mount point. It
> uses that file to store persistence information. This could be overridden
> with a kernel option or mount option to tell it not to store persistent
> information (for e.g. rom filesystems).
Hmm, I think the first idea works better, have a /dev with actual
files on it which have permissions and whatnot, all in ext2. Then when devfs
starts up, if /dev exists, it reads it and uses it for permissions. Hmm, I'd
actually suggest saying that it also shows the devices in /dev even if it
doesn't find them in the system. If it does find them, it should have some
way of matching them up, catch my drift? Or at least working around them.
Something where, you have /dev/dsk/c0t0d0s0, then you add a new
controller in a different PCI slot, and take out the first one, well, if
possible it'd be kind of nice to have the new controller come up as
/dev/dsk/c1t0d0s0. I'm just thinking here, so this might not be the best
idea.
Hmm, perhaps a /devices that is set up based off of (as best it
can figure it out) hardware information, whereby you have it be this UnionFS
with the permissions and whatnot stored in the background, and then you have
a userspace tool that scans through /devices (When you run it, not
automagically) and creates symlinks in /dev to things in /devices? Though
it is carefull to never delete symlinks, that should be a manual operation.
(Or at least a seperate one).
Then you have daemons for hot-swap devices that can create symlinks
to newly created things in /devices. Again, brain storming, so perhaps this
is uglier than it should be...
> The kernel already does something like this for quotas, doesnt it?
It may, not TOO familiar w/ how quotas work exactly.
Stephen
-
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/