Subject: Re: kern.showallprocs implementation
To: Thor Lancelot Simon <tls@rek.tjls.com>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 08/30/2005 19:44:44
--qDymnuGqqhW10CwH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Aug 30, 2005 at 06:33:31PM -0400, Thor Lancelot Simon wrote:
> On Wed, Aug 31, 2005 at 08:18:17AM +1000, matthew green wrote:
> > =20
> > Bottom line is that these features are not any ``BSD security model''
> > that was discussed; it's a collection of commonly requested features
> > as implemented in FreeBSD. I see no reason to keep any compatibility.
> >=20
> >=20
> > i think more importantly these are arguments that keeping
> > compatibility is bad. the `bsd' subnode is confusing and
> > for this reason we shouldn't use it.
>=20
> I strongly agree. I do not think that FreeBSD provides, in general, a
> sufficiently good example of sysctl naming nor of security design nor
> functionality that we should hesitate to go our own way in either regard.
I'm not really sure what to say. I have strong feelings about the one node=
=20
vs lots of knobs question, but really don't care so much about the name,=20
as long as it stands some chance of surviving into whatever extended=20
scheme we come up with. The name doesn't have to, but I'd rather not pick=
=20
something so ugly/stupid that we know it will go. :-)
I'm not trying to say we should pick the FreeBSD name because FreeBSD is a
great icon. I suggested it because it seemed to make sense, and all other
things being equal, I think it's good to go w/ prior art. "security"."some
subection name"."a node name" seems rather sane. It indicates that it's
security, and I'd expect "some subsection name" would limit the space to
uid/gid based controls. "bsd" kinda makes sense, and I can't think of=20
anything better (I've tried!).
And no other name really stands out. We've been hashing over this for a
few days and no name has jumped out as "THE" name for everyone, as
evidenced by the fact we're still hashing it. :-)
So given that we seem to be in a morass, why not go with the "not insane=20
prior art" option?
Take care,
Bill
--qDymnuGqqhW10CwH
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
iD8DBQFDFRmcWz+3JHUci9cRAtpnAJ9GW1LL98/OpSZwW7kQrcjRtn0XIgCfZ2tQ
5B8Ms0uODe5/YK8mSscfqwQ=
=TAC/
-----END PGP SIGNATURE-----
--qDymnuGqqhW10CwH--