Date: Mon, 16 Feb 1998 11:45:05 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: "John S. Dyson" <toor@dyson.iquest.net>, Bruce Evans <bde@zeta.org.au>, dyson@FreeBSD.ORG, wollman@khavrinen.lcs.mit.edu, committers@FreeBSD.ORG, eivind@yes.no Subject: Re: devfs persistence Message-ID: <Pine.BSF.3.95.980216114100.8949C-100000@current1.whistle.com> In-Reply-To: <199802150234.TAA24906@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980216114100.8949C-100000>