Date: Thu, 3 Apr 1997 01:21:14 +1000 (EST) From: proff@suburbia.net To: avalon@coombs.anu.edu.au (Darren Reed) Cc: hackers@freebsd.org Subject: Re: devfs Message-ID: <19970402152114.27776.qmail@suburbia.net> In-Reply-To: <199704021415.GAA01403@freefall.freebsd.org> from Darren Reed at "Apr 3, 97 00:10:35 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. :-) Perhaps I didn't make it clear enough. sysctl provides the names of the devices only. Since this information can't be changed, it doesn't need persistance. All persistent information (i.e everything you normally see in a struct stat) is stored "on the disk" in LNKDEV inodes. > > then passed on to namei()? You could get variant symlink behaviour 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 > > darren Yes, I remember my Pyramid fondly. It not only provided two universes, but heated the whole house as well, drinking around $10 a day in power :) The kernel shouldn't be handling these name space hacks. One world view of mount points isn't a good thing. This should all be done in libc, ala plan9/VSTa. Such a thing has already started with the introduction of modifications to readdir(3) for unions. Once again though, this is more in the manner of a gross hack than any consistent or modular approach. There are very good solutions to this, but as far as I see -core is too conservative entertain such a deviation from the BSD path. You could say it is not the place for FreeBSD to be a research platform - but I'd have to disagree here and say that the research here is quite mature and proven. As for your variant on the sysctl idea, I like it, but I don't think it has any benefit for the devfs problem :) Cheers, Julian.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970402152114.27776.qmail>