Date: Wed, 02 Apr 1997 21:59:35 +0100 From: Brian Somers <brian@awfulhak.org> To: Darren Reed <avalon@coombs.anu.edu.au> Cc: jkh@time.cdrom.com (Jordan K. Hubbard), proff@suburbia.net, hackers@freebsd.org Subject: Re: devfs Message-ID: <199704022059.VAA14510@awfulhak.demon.co.uk> In-Reply-To: Your message of "Thu, 03 Apr 1997 00:10:35 %2B1000." <199704021415.GAA01403@freefall.freebsd.org>
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
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 <brian@awfulhak.org>, <brian@freebsd.org>
<http://www.awfulhak.demon.co.uk/>;
Don't _EVER_ lose your sense of humour....
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704022059.VAA14510>