Bill Studenmund wrote:
> 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.
>>
>> 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 
> folks how to spend their time. If someone wants to add this, what really 
> is wrong with it, other than you would have wanted something else? It's 
> not like we're adding a feature that lets a user gain root privs or 
> 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 
> adding sysctl interfaces for a program to get data. I believe they are 
> not. I personally feel quite confident that I can add a sysctl to expose a 
> string or int already in the kernel. I am not at all confident I can add 
> 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 
> fact think it'd be good. I however think we should not tell folks to NOT 
> add features because they didn't remove kvm groveling.
>   

My point is, I don't want to add features that encourage further kvm
groveling.

Here are my major complaints with kvm groveling:

1) the obvious problem of finding a matching kernel -- if you don't boot
from a kernel stored in the root filesystem (and even then, the problem
this kind of solution is trying to solve to determine *which* file)

2) it requires these applications to have direct access to kmem, making
us leave them running at higher privilege then they necessarily need. 
(I.e. kvm grovelers *are* a security risk.)

3) some systems don't have a kernel in the root filesystem at all.  e.g.
embedded systems with an "md" root filesystem.  kvm grovelers either
don't work, or you wind up having to waste a *lot* of memory keeping
another copy of your kernel around in the md root in order to let them work.

For these reasons, I really, really don't think we should be making it
any easier to use kvm grovelers at all.  Anyone sophisticated enough to
be hacking on kvm grovelers *should* be able to figure out how to make
sysctl work.  If they aren't, then they *probably* shouldn't be hacking
on kvm grovelers because of point #2 above.

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191