From owner-freebsd-hackers  Wed Apr  2 06:15:51 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id GAA01410
          for hackers-outgoing; Wed, 2 Apr 1997 06:15:51 -0800 (PST)
Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA01403
          for <hackers@freebsd.org>; Wed, 2 Apr 1997 06:15:47 -0800 (PST)
Message-Id: <199704021415.GAA01403@freefall.freebsd.org>
Received: by cheops.anu.edu.au
	(1.37.109.16/16.2) id AA295340235; Thu, 3 Apr 1997 00:10:35 +1000
From: Darren Reed <avalon@coombs.anu.edu.au>
Subject: Re: devfs
To: jkh@time.cdrom.com (Jordan K. Hubbard)
Date: Thu, 3 Apr 1997 00:10:35 +1000 (EST)
Cc: proff@suburbia.net, hackers@freebsd.org
In-Reply-To: <273.859968918@time.cdrom.com> from "Jordan K. Hubbard" at Apr 2, 97 00:15:18 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
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

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