Subject: Re: kern.showallprocs implementation
To: Elad Efrat <elad@NetBSD.org>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 08/26/2005 15:25:53
Content-Type: text/plain; charset=us-ascii
On Fri, Aug 26, 2005 at 11:47:46PM +0300, Elad Efrat wrote:
> Bill Studenmund wrote:
> > 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=
> > 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=
> 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=
actually get the code soon. :-) Things happen...
> > "I think these changes will be a mistake" is a good reason to not make =
> > change. "I want something better," when we don't have code for "better,=
> > doesn't seem like a good reason.
> 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"?
> 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?
> > Elad, would this change HURT the "broader" change you have in mind?
> Yes, because users will get used to something.
So? So the sysctl moves? Folks can cope with that. And we can add the old=
value as a COMPAT_WHATEVER option.
> > If=20
> > not, let's add this for now and then when you have code, we can review =
> > and let it replace this change.
> 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=
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=
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,=
and if we have an idea for future directions, maybe we should choose a=20
different name (as your other post notes).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----