From owner-cvs-all Mon Feb 16 11:53:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA08858 for cvs-all-outgoing; Mon, 16 Feb 1998 11:53:24 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA08697; Mon, 16 Feb 1998 11:52:30 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id LAA05147; Mon, 16 Feb 1998 11:49:00 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd005145; Mon Feb 16 11:48:56 1998 Date: Mon, 16 Feb 1998 11:45:05 -0800 (PST) From: Julian Elischer To: "Justin T. Gibbs" cc: "John S. Dyson" , Bruce Evans , dyson@FreeBSD.ORG, wollman@khavrinen.lcs.mit.edu, committers@FreeBSD.ORG, eivind@yes.no Subject: Re: devfs persistence In-Reply-To: <199802150234.TAA24906@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk I like Justin's ideas. I also like mikes ideas in some cases.. I think I can make something that will me a clean mix of these. julian (been away 2 days skiing) On Sat, 14 Feb 1998, Justin T. Gibbs wrote: > >It is an issue of being able to cleanly and straightforwardly support embedded > >products. > > The biggest advantages I see in DEVFS are the possibility to eliminate all > of the unit->softc/static array translation cruft that is currently > performed in the kernel as well as remove any device numbering limitations. > Just take a look at all of the 32bit dev_t nonsense in the NetBSD lists to > see how flawed the current approach is. > > I think that the persistence problem with DEVFS is solvable and if/when it > is proved to be so, why do we need to provide the old mechanism? > > Here are my thoughts on the persistence problem: > > 1) Use an underlying file per node, to represent permission and "whiteout" > overrides. The semantics for modification of these files will need some > thought. For instance, if the DEVFS is not mounted on top of these files, > you don't want to allow John Doe to be able to write to them. I don't > think however, as someone once suggested, they should be "invisible". > > 2) To handle special chroot environments (e.g. ftp), provide a special > DEVFS mounting option. This option would essentially say that no matter > what devices exist in the system, only nodes that have a backing file will > be shown. To setup an FTP area, the sysadmin would have to setup these > backing objects by perhaps mounting an additional instance of DEVFS in the > target location, removing the devices that are not wanted, and using a > utility to "checkpoint" the nodes that still exist. Then, in /etc/fstab, > add in the additional entry for the second instance of DEVFS with the > option set. The fact that "new devices" don't auto-magically show up in > the chroot area is by design and is essentially the same behavior we have > now (you have to perform a MAKEDEV in the chroot area to a new device show > up). > > 3) Only root should be able to mount a DEVFS. > > 4) At secure levels above X (0???), additional DEVFS file system instances > cannot be created. > > -- > Justin > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message