From owner-freebsd-current Fri Feb 9 13:07:38 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA11515 for current-outgoing; Fri, 9 Feb 1996 13:07:38 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA11508 for ; Fri, 9 Feb 1996 13:07:34 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA11190; Fri, 9 Feb 1996 14:03:24 -0700 From: Terry Lambert Message-Id: <199602092103.OAA11190@phaeton.artisoft.com> Subject: Re: FS PATCHES: THE NEXT GENERATION To: julian@ref.tfs.com (Julian Elischer) Date: Fri, 9 Feb 1996 14:03:24 -0700 (MST) Cc: jkh@time.cdrom.com, phk@critter.tfs.com, terry@lambert.org, current@freebsd.org In-Reply-To: <199602092025.MAA00293@ref.tfs.com> from "Julian Elischer" at Feb 9, 96 12:25:15 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk > 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.