From owner-cvs-all Fri Feb 13 15:56:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA08374 for cvs-all-outgoing; Fri, 13 Feb 1998 15:56:09 -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 PAA07710; Fri, 13 Feb 1998 15:52:48 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id PAA04110; Fri, 13 Feb 1998 15:43:46 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd004108; Fri Feb 13 15:43:45 1998 Date: Fri, 13 Feb 1998 15:39:57 -0800 (PST) From: Julian Elischer To: "Justin T. Gibbs" cc: Paul Traina , Mike Smith , core@FreeBSD.ORG, junichi@jp.freebsd.org, committers@FreeBSD.ORG Subject: devfs persistance In-Reply-To: <199802132317.QAA19919@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk 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