Robert Elz wrote:
> me particularly noticing).   In general I don't think a lot of the
> "do a quick change, test it, didn't work, how about this, ..." style
> of programming - that may be because I learned to program back in the

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.

So far, I found ability to quickly test changes VERY comfortable.  I also
really appreciate LKMs in in initial stage of tracking down a bug - it's
easy to put printf's here and there and to investigate and to understand
what's going on.

> analysing it).   So, for me, a reboot to test a new feature isn't
> a problem, it is only likely to happen twice a day - once to do the
> first test, then again to fix the really stupid error and allow
> the real test to take place...

Heh, I sure prefer a bit shorter round-trip time :)

But consider this one of those "today-people-don't-know-how-to-do-things-right"
rants :)

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.

> So, I guess that if it was to be a choice between retaining a
> monolithic kernel, and switching to an "everything is an LKM",
> then I'd be supporting the monolithic kernel every time.

Me too. Nobody is arguing for making everything a LKM. Old
LKMs bitten me couple of times already and I prefer to build
custom kernel when I don't need the flexibility of LKMs. I'd be
really annoyed if ability to build monolithic kernel would be lost.

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>      http://www.ics.muni.cz/~dolecek/
@@@@  Wanna a real operating system ? Go and get NetBSD, damn!  @@@@