Subject: Re: LKMs
To: Jarommr Dolecek <>
From: Robert Elz <kre@munnari.OZ.AU>
List: tech-kern
Date: 11/26/2000 21:32:10
    Date:        Sun, 26 Nov 2000 11:09:15 +0100 (CET)
    From:        Jarommr Dolecek <>
    Message-ID:  <>

I will reply to just this one message...

  | Note: LKMs are not about making quick changes, it's about ability to do
  | quick testing - you don't need to reboot just to find out you made
  | off-by-one error (or anything silly like that) and reboot again.

Well, depending upon the error, you should get to save one of the reboots,
you might get to save the other.  But I don't think that putting code in
an LKM makes it immune from trashing the system...

  | Most of code I deal with is written by someone else. That makes
  | the "I know where the problem is" approach a bit harder to apply.

The "I know where the problem is" approach is one of the easy ways
to mess thing sup totally...

Whoever wrote the code, the best way (by a long way) to debug it is
to read and understand it first.   However difficult that is.
(Aside from compilation problems, which can generally be fixed
easily - and of course if it compiles and works, then there's no
need to debug, and hence no need to understand, though the desire
might remain).

  | Me too. Nobody is arguing for making everything a LKM.

Actually, there was one suggestion along those lines, that's what
inspired my message.

Also, note, that I never intended to imply that LKMS should be deleted
from NetBSD (though if they make tool aided debugging (as distinct from
printf and see where it goes debgging) as difficult as Darren suggested,
I can see why some might want to...).

Nor did I mean to imply that people comfortable with them should not
use them.

All I meant, that is what I intended to say, was that I might one day
use one, then again perhaps not, because ...    That is, just explaining
my motivations for not necessarily believing that using LKMS for easy
kernel debugging is necessarily the right way (the turnaround time on
a kernel rebuild and reboot on most systems these days is so quick that
doing it that way isn't much of a slow down anyway - even that doesn't
give time to think.   If I hadn't asked everyone else not to, I would
remember the days when....)