From owner-freebsd-hackers Wed Apr 2 13:15:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA24659 for hackers-outgoing; Wed, 2 Apr 1997 13:15:59 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA24627 for ; Wed, 2 Apr 1997 13:15:53 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.lan.awfulhak.org [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id VAA14510; Wed, 2 Apr 1997 21:59:35 +0100 (BST) Message-Id: <199704022059.VAA14510@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: Darren Reed cc: jkh@time.cdrom.com (Jordan K. Hubbard), proff@suburbia.net, hackers@freebsd.org Subject: Re: devfs In-reply-to: Your message of "Thu, 03 Apr 1997 00:10:35 +1000." <199704021415.GAA01403@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Apr 1997 21:59:35 +0100 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 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 ln -s /bin att=/.attbin ucb=/.ucbbin It was horrible because att didn't know about symlinks. All it takes is someone to symlink . to .. and att can't hack it. > 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. [.....] You could (if it worked) mount a unionfs on top of devfs if you want any sort of persistence. It'd be nice and easy to "clean up" dev too ! -- Brian , Don't _EVER_ lose your sense of humour....