Date: Fri, 13 Feb 1998 15:39:57 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: Paul Traina <pst@juniper.net>, Mike Smith <mike@smith.net.au>, core@FreeBSD.ORG, junichi@jp.freebsd.org, committers@FreeBSD.ORG Subject: devfs persistance Message-ID: <Pine.BSF.3.95.980213151948.23295G-100000@current1.whistle.com> In-Reply-To: <199802132317.QAA19919@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Actually there is a strong argument that persistance in /dev is not a good idea.. ask phk on the topic.. Given that some people think this is useful and insist on it however, the planned implementation of the persistance misfeature is as follows. This is actually the only part not implememted.. devfs grows a unionfs type of characteristic, where the namespace is shadowed onto the root fs underneath with empty inodes (no data, just the persistant info, e.g. owner, perms normal files, not special nodes either) devices do not grow a lower 'apendage' until manually given a permission or owner. the lower appendages cannot be seen on their own unless there is a devfs node that matches them. Three mount modes are also added. 1/ only show nodes that are already existant on the lower (ufs) layer. 2/ don't look for a lower layer (the default at present obviously) 3/ create lower nodes as needed (#3 this could lead to proliferation of invisible nodes on the root fs if some devices change names, but I think this is unavoidable in any form of persistance on a devfs as you never know when a node is going to come back. How long does persistance last? As I said, I think persistance in the devfs is a complete misfeature anyhow, as does phk.) The first mode would allow you to populate a chroot /dev with only known and trusted items. This is the strongest reason for this unionfs idea and not the persistance boondoggle. On Fri, 13 Feb 1998, Justin T. Gibbs wrote: > >the reluctance of core people to try out devfs is the only reason for > >it's non existance in the current tree as far as I can see. > > I have yet to see a document explaining how DEVFS deals with permission > persistence, including persistence in chroot environments. If this issue > is already solved, then I will happily endorse DEVFS and any measures that > are taken to remove dev_t from the kernel. It's solved but not fully implemented as no-one has actually needed it yet. > > -- > 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.980213151948.23295G-100000>