Date: Wed, 02 Apr 1997 00:15:18 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: proff@suburbia.net Cc: hackers@freebsd.org Subject: Re: devfs Message-ID: <273.859968918@time.cdrom.com> In-Reply-To: Your message of "Wed, 02 Apr 1997 17:54:33 %2B1000." <19970402075433.19722.qmail@suburbia.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 1) accept that devfs in it's present form is a kludge. Move > all the default permissions and device numbers into a > sysctl hierarchy. This hierarchy is then used to create > names in /dev. Add a new ufs file type: S_IFLNKDEV. > When a namei occurs on what this pseudo-symlink points > to, it looks up name in the sysctl and returns the inode > of the "symlink" with device numbers filled in. The I'm not sure if I care much for this as a solution to the persistance problem, at least not unless you were also talking about having DEVFS manipulate this piece of the sysctl namespace on behalf of the user for any modifications they may make. It has to be transparent after setup, right? Also, I don't think that anyone has addressed the issue of sysctl MIB persistance either yet, so your changes would still go away on reboot. :-) Still, what you *do* raise here is an interesting, possibly even downright evil, idea (and I like the evil ones best ;). How about a new symlink type which is just like a classic symlink in every way except that its value, rather than being direct fodder for namei(), is instead used to look something up in sysctl, the value of THAT being then passed on to namei()? You could get variant symlink behavior by poking things into sysctl. :-) > 2) code a light "permission union" file system. this file > system type would work like unionfs, but with file permissions > only. Mount devfs on /dev and the permission union > over the top. When ever permissions are changed from the > default an entry is created in the upper layer. That idea has the most promise, I think, even with its limitations. People like Sean Eric Fagan have also suggested that devfs attempt to open a file at the mountpoint before proceeding to mount the devfs over it. If it succeeds, it's now got a handy "hidden" file handle in which to write a little transaction log to. When you remount it later, it sees the file already existing, does a quick sanity check on it and reapplies all the state (leaving it open for append afterwards, of course). Sort of like a journaling devfs or something. :-) That would also give you the multiple view model for different mount points. Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?273.859968918>