Subject: Re: @booted_kernel magic symlink?
To: Garrett D'Amore <garrett_damore@tadpole.com>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 04/26/2006 10:03:32
--TakKZr9L6Hm6aLOc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 25, 2006 at 04:32:11PM -0700, Garrett D'Amore wrote:
> matthew green wrote:
> My objection was that if we were going to change programs or kernel code
> to support this, then that effort would be best spent just making them
> use sysctl.  If, however, there are no kernel changes to support this,
> and the changes to userland programs are trivial enough than any idiot
> can make them, then I will withdraw my objection.
>=20
> If a kernel developer is seen making these changes though, then he/she
> should be smacked and the effort should be to make whatever program
> needs this use sysctl instead.

Why?

I have two objections to your proposal above. 1) You're telling other=20
folks how to spend their time. If someone wants to add this, what really=20
is wrong with it, other than you would have wanted something else? It's=20
not like we're adding a feature that lets a user gain root privs or=20
something silly like that; I fail to see how it will really hurt.

2) You're assuming that adding a sysctl to get a string is as hard/easy as=
=20
adding sysctl interfaces for a program to get data. I believe they are=20
not. I personally feel quite confident that I can add a sysctl to expose a=
=20
string or int already in the kernel. I am not at all confident I can add=20
the data marshaling needed to replace a kvm groveler.

I'm not disagreeing that it'd be nice to get rid of kvm-groveling, I in=20
fact think it'd be good. I however think we should not tell folks to NOT=20
add features because they didn't remove kvm groveling.

Take care,

Bill

--TakKZr9L6Hm6aLOc
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFET6fkWz+3JHUci9cRApKtAJ473ORLrP9GMnYKOr0d1dLRLBwucACfUfKL
8jYkWYTa9pWKqXA6xKZ4tLc=
=RkZW
-----END PGP SIGNATURE-----

--TakKZr9L6Hm6aLOc--