Date: Fri, 13 Feb 1998 16:28:02 -0800 From: Mike Smith <mike@smith.net.au> To: Julian Elischer <julian@whistle.com> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, Paul Traina <pst@juniper.net>, Mike Smith <mike@smith.net.au>, core@FreeBSD.ORG, junichi@jp.freebsd.org, committers@FreeBSD.ORG Subject: Re: devfs persistance Message-ID: <199802140028.QAA05427@dingo.cdrom.com> In-Reply-To: Your message of "Fri, 13 Feb 1998 15:39:57 PST." <Pine.BSF.3.95.980213151948.23295G-100000@current1.whistle.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.. I have. His argument supports persistence, using a poor technique. > 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. That's getting there, but you are leaving out phk's (very valid) desire to be able to prototype attributes for nonexistent nodes. To me, this speaks of two entities: - A set of rules, which are scanned as the node is being created. Having passed through these rules, the node may have had its attributes, etc. modified before it appears in the namespace. These allow the implementation of the "prototyping" behaviour. - A list of explicit nodename : attribute associations. These allow the implementation of the DWIM chown/chmod behaviour. IMHO, these should be stored in files under the mountpoint. The devfs code would have to look this file up during the mount, and keep it open. You could also supply a systemwide copy of the data either from a configuration file or via inheritance from the first mount of the devfs. If you didn't like persistence, then you could simply ignore it. > > 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. This is a misstatement. It's not implemented, thus DEVFS/SLICE has not been adopted. When it is, it will be. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com 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?199802140028.QAA05427>