Date:        Mon, 20 Feb 2006 01:02:31 -0800
    From:        "Garrett D'Amore" <garrett_damore@tadpole.com>
    Message-ID:  <43F985A7.3060904@tadpole.com>

  | New guy here, but it strikes me that the only likely reason not to have
  | it (assuming you have IP networking) is the resource burden.

With the other noise that is in GENERIC (for several ports) I kind of
doubt that's really the issue (it might be for some architectures,
which typically have a rather lean GENERIC, and can remain that way).

  | There seems to be some work towards LKM to assist in this.

Personally, I'd prefer to see support for LKMs simply dropped...

Not that I expect that to happen, but for an OS distributed in source
form, the real demand for LKMs should be pretty small (really only for
those occasions when you cannot predict when you boot the kernel
just what support you might need - so perhaps I might consider an
ext2fs LKM, just in case someone brought me a floppy, or thumb drive,
with an ext2fs file system on it and asked me to read it - but even
there I think I'd just prefer userland file system access tools - as
in an application that reads the drive and extracts files as requested,
kind of like mtools).

Aside from that, LKMs just add overhead in order to achieve laziness.

Rather than LKMs, I'd much prefer to see (someone else's...) effort
spent on better kernel config tools.

  |     3) there needs to be better linkage between probing a bus and the
  | module info.  See for example Solaris' driver_aliases file.

Vendors who ship binary OS releases have lots of very good reasons to
put a lot of work into LKM support.  So I absolutely understand that
kind of thing for Solaris.   Similarly, anyone who wants to ship binary
versions of NetBSD most likely should be spending a bunch of effort for
making the LKM system work really well.   But that does not need to a
be a TNF objective (IMO).

kre

ps: none of this was in any way relevant to the original question of course.