Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 Feb 1996 14:03:24 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        julian@ref.tfs.com (Julian Elischer)
Cc:        jkh@time.cdrom.com, phk@critter.tfs.com, terry@lambert.org, current@freebsd.org
Subject:   Re: FS PATCHES: THE NEXT GENERATION
Message-ID:  <199602092103.OAA11190@phaeton.artisoft.com>
In-Reply-To: <199602092025.MAA00293@ref.tfs.com> from "Julian Elischer" at Feb 9, 96 12:25:15 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> I think that the principal of least astonishment has to be balanced against
> the problem of staying in the dark ages.

Here here!

> I think that mount_devfs should be able to look somewhere for a
> configuration script regarding the filesystem it's making. however there
> is NO ANSWER anywhere, for what to do about a new device that just pops up...

Permissions need to be part of the export information, like default user
and group ownership.

That is, defaults are provided by the device itself.

As far as mount_devfs: I'd leave it out.  You don't want to *ever*
unmount the thing, and you want to *always* mount the thing -- or rather
stuff it into the namespace.

The one potential exception is to template and reexport the namespace
elsewhere, for instance an ftpd chroot'ed environment.  In reality,
this should probably be handled via a special case of union or loopback
mount.

Other than that, "/devfs" should be mounted as mandatorily as "/" is
mounted now.


Some of the proposed mount changes I suggested would be useful for
setting up "local root" per FS as volume designations, then mapping
the devfs "volume" into the root FS or into the chrooted environment
this way.

For instance, automounting devfs as volume "//devfs", followed by
mapping ("mounting") "//devfs/" to "/dev" as a "mount".  Default
volume permissions can prohibit access to non-root (or not) as
desired.  For instance, a symlink to the POSIX mandated escape could
let you default permissions on a CDROM device such that the symlink
resulting from the following command allows access of an intermittently
available common CDROM resource:

	ln -s //cdrom0/ /cdrom

Escapes further into the name space would allow volume identification

	ln -s "//cdrom0:CIA Map Database/" /cdrom/cia

And then cause an operator mount request, etc..


This would all have to wait until everything that could be mounted
is mounted by the device discovery process calling back the mount
code during device "registration" of each slice, or whatever.

-current does not need to be generally usable for all potential
applications at any given time; look at the recent CCITT hoo-rah.
Delaying anon FTP server usability until a loopback or multi-instance
mount capability exists seems like an acceptable thing to do, as
long as the condition doesn't persist too long.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602092103.OAA11190>