--TBNym+cBXeFsS4Vs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 26, 2005 at 11:47:46PM +0300, Elad Efrat wrote:
> Bill Studenmund wrote:
>=20
> > Elad, please be VERY careful with comments like this. I've seen comments
> > like this come by in the past, something happen to the developer intend=
ing
> > to work on X (something gets in the way of the work), and so "very near
> > future" turns into years, with no improvement to NetBSD in the mean tim=
e.
>=20
> I wouldn't make such a comment if I didn't plan on doing the exact same
> thing, in a more generic and extendable way, very soon.

I do not doubt that that is your intent. However that doesn't mean we will=
=20
actually get the code soon. :-) Things happen...

> > "I think these changes will be a mistake" is a good reason to not make =
a=20
> > change. "I want something better," when we don't have code for "better,=
"=20
> > doesn't seem like a good reason.
>=20
> How about "I don't like the way FreeBSD did it. I'd rather have a
> kern.privacy node where we could set filters for various parts of the
> system that use sysctl"?
>=20
> One of the things I'm doing is changing kvm(3) use for live kernel reads
> to sysctl(3) calls. I've done this for PF_INET in netstat. Some people
> want to be able to filter connections not owned by the user. Do you
> think we should add a kern.showallinetconnections as well?

Porbably not.

> > Elad, would this change HURT the "broader" change you have in mind?
>=20
> Yes, because users will get used to something.

So? So the sysctl moves? Folks can cope with that. And we can add the old=
=20
value as a COMPAT_WHATEVER option.

> > If=20
> > not, let's add this for now and then when you have code, we can review =
it=20
> > and let it replace this change.
>=20
> When did this become so urgent? If it is, I'll commit code *now*.
> However, I don't think this is critical enough to be a top priority,
> especially not when I'd rather something like this be well designed.

It became "urgent" when folks noticed that something that looked done had=
=20
gone nowhere in upwards of a year.

And as to designing things well, we do that a lot with NetBSD. However=20
sometimes we spend more time designing than doing, and let the pursuit of=
=20
the "ideal" design stop us from making positive change.

> The same project from which we imported most of the new Veriexec also
> had privacy hooks. The code is already written and tested, but as I
> said - if this is something that gets into base, let's think it a bit
> more than an ugly ``showallprocs'' knob...

I personally do not find it that ugly. Yes, that scheme won't scale well,=
=20
and if we have an idea for future directions, maybe we should choose a=20
different name (as your other post notes).

--TBNym+cBXeFsS4Vs
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFDD5bxWz+3JHUci9cRAsh3AJ9y0lhQ0EcStPBh/ADQ/BZAwjm70wCfXAV/
9YJZyB2mws9xwfUjNY05c54=
=jDqj
-----END PGP SIGNATURE-----

--TBNym+cBXeFsS4Vs--