Date: Sat, 14 Feb 1998 19:31:40 -0700 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: "John S. Dyson" <toor@dyson.iquest.net> Cc: bde@zeta.org.au (Bruce Evans), dyson@FreeBSD.ORG, wollman@khavrinen.lcs.mit.edu, committers@FreeBSD.ORG, eivind@yes.no Subject: Re: devfs persistence Message-ID: <199802150234.TAA24906@pluto.plutotech.com> In-Reply-To: Your message of "Sat, 14 Feb 1998 20:43:16 EST." <199802150143.UAA00354@dyson.iquest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>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?199802150234.TAA24906>