Date: Thu, 3 Apr 1997 00:10:35 +1000 (EST) From: Darren Reed <avalon@coombs.anu.edu.au> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: proff@suburbia.net, hackers@freebsd.org Subject: Re: devfs Message-ID: <199704021415.GAA01403@freefall.freebsd.org> In-Reply-To: <273.859968918@time.cdrom.com> from "Jordan K. Hubbard" at Apr 2, 97 00:15:18 am
next in thread | previous in thread | raw e-mail | index | archive | help
In some mail from Jordan K. Hubbard, sie said: > > > 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. :-) OSx5.1 (ye olde syvr3/4.2bsd mix) from Pyramid nhad a "conditional" symbolic link (if I remember right) worked something like this: ln -c att /.attbin -c ucb /.ucbbin /bin where 'att" and "ucb" where two "universes". Depending on which one you were in at the time (process property) /bin was either /.attbin or /.ucbbin. I think FreeBSD should start out with devfs under a different / directory, maybe /devices (;). Let devfs co-exist with /dev, getting a feel for it over time, and at some point, start moving things over to /devices using symbolic links. Eventually, /dev becomes a symlink to /devices. Or... if only name & permission persistance is sought, why can't devfs inherit permissions from /dev and just change major/minor #'s (or is persistance required there too) ? maybe mounting devfs needs to be a boot "procedure" where name->permissions ownership is transfered from /dev to /devices. Hmmm, what if /dev was a sym. link to /dev.old (or was reset to that at boot time), then after the devfs block was mounted under /devices and attributes transfered, changed to point to /devices ? darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704021415.GAA01403>