Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 14 Feb 1998 13:08:12 +0000
From:      Brian Somers <brian@Awfulhak.org>
To:        Julian Elischer <julian@whistle.com>
Cc:        Mike Smith <mike@smith.net.au>, Poul-Henning Kamp <phk@critter.freebsd.dk>, committers@FreeBSD.ORG
Subject:   Re: devfs persistance 
Message-ID:  <199802141308.NAA00711@awfulhak.org>
In-Reply-To: Your message of "Fri, 13 Feb 1998 17:26:36 PST." <Pine.BSF.3.95.980213171931.23295X-100000@current1.whistle.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> ah.. now I LIKE some of this....
> I see some possibilities here..
> I'll think about this over the weekend..
> 
> devfs could REFLECT file accesses to /dev/defaults through to a real file
> used for persistance.  hmmmm it doesn't need to be UNDER the devfs. (any
> more than wd0s1e needs to be 'under' /usr) I still don't think chmod
> should alter this file however..  but the specific entries.. 
> need to be stored somewhere.. blank vnodes underneath still
> sound good to me for this.

I don't like the idea of /dev/defaults.

If DEVFS stores all of this stuff under the mount point in some file, 
it should *only* store information pertaining to stuff made previously 
available through DEVFS.  The persistence is there, but only for stuff 
that should be persistent.  This has nothing to do with policies that 
people want to associate with new devices.

The whole ``devices coming and going'' idea is a completely different 
problem.  At the moment we have /dev/MAKEDEV where we write our 
policies.  We may need to make DEVFS capable of understanding some 
sort of policy file with lines saying "device: 644 root.wheel" and a 
default line at the end, but I don't think this should defer the 
implementation of DEVFS.

If it's done this way, we have a paradigm similar to the existing 
one.  Once something in /dev is there, it says there in the same 
state that it was last time we looked (except it may "go and come").  
When something new is added, we must be careful to give it the 
correct permissions.  This has always been the case.
-- 
Brian <brian@Awfulhak.org>, <brian@FreeBSD.org>, <brian@OpenBSD.org>
      <http://www.Awfulhak.org>;
Don't _EVER_ lose your sense of humour....



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802141308.NAA00711>