Bill Studenmund wrote:
> On Wed, Apr 26, 2006 at 10:30:04AM -0700, Garrett D'Amore wrote:
>   
>> Bill Studenmund wrote:
>>     
>>> On Tue, Apr 25, 2006 at 04:32:11PM -0700, Garrett D'Amore wrote:
>>>   
>>> 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.
>>     
>
> No one is disagreeing with the above. And also, this thread wasn't about 
> adding NEW kvm grovelers, it was about making it easier to find the booted 
> kernel.
>
> The irritating thing about your complaint is that the initial point of the
> thread was to try and address your complaints (1) and (3). :-) It doesn't
> seem fair to use complaints about something as reasons to NOT address
> those very complaints!
>   

This does nothing for complaint number 3.  (Unless you also have a
kernel in a *filesystem* somewhere.  Which it might well not be.  E.g.
for a compact embedded system you don't want to duplicate the kernel
anywhere, and it might be on a device that doesn't have a mountable
filesystem on it.)  And by resolving  complaint number 1, it reduces the
likelihood that anyone will spend time working on complaints number 2 and 3.
>
> I guess another reason I don't think making it easier to find the booted 
> kernel would be bad is that I've seen us all-too-often direct features 
> like this, and the net result is that we end up lacking features.
>   

See, I see it another way, which is that by not taking the time to DTRT,
we band-aid ourselves into a corner where problems #2 and #3 never get
fixed, because "most users" with laptops and local disks can live with
it that way.  (Of course, if they just work around this by making sure
/netbsd is a copy of their booted kernel, then it *also* works now.)

If I had a little more time, I'd go ahead and try to fix the kernel
grovelers myself.  I don't know how many of them are out there, but
there aren't many.

Does adding this feature actually really solve a major problem?  I doubt
it.  Anyway, if the group feels its important to band-aid this
half-solution to one-third of the problem, then I will STFU now.

    -- Garrett


-- 
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