From owner-freebsd-questions  Mon Jan 12 08:39:30 1998
Return-Path: <owner-freebsd-questions>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id IAA25002
          for questions-outgoing; Mon, 12 Jan 1998 08:39:30 -0800 (PST)
          (envelope-from owner-freebsd-questions)
Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id IAA24648
          for <freebsd-questions@FreeBSD.ORG>; Mon, 12 Jan 1998 08:36:01 -0800 (PST)
          (envelope-from rhh@ct.picker.com)
Received: from ct.picker.com by whqvax.picker.com with SMTP;
          Mon, 12 Jan 1998 11:34:35 -0500 (EST)
Received: from elmer.ct.picker.com by ct.picker.com (4.1/SMI-4.1)
	id AA29999; Mon, 12 Jan 98 11:34:26 EST
Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4)
	id LAA15944; Mon, 12 Jan 1998 11:33:17 -0500
Message-Id: <19980112113317.04967@ct.picker.com>
Date: Mon, 12 Jan 1998 11:33:17 -0500
From: Randall Hopper <rhh@ct.picker.com>
To: Greg Lehey <grog@lemis.com>
Cc: Jason Wells <jcwells@u.washington.edu>, freebsd-questions@FreeBSD.ORG
Subject: Re: LKM versus Static Kernel
References: <3.0.3.32.19980104175505.007cc9b0@jcwells.deskmail.washington.edu> <19980110195048.17940@lemis.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.81
In-Reply-To: <19980110195048.17940@lemis.com>; from Greg Lehey on Sat, Jan 10, 1998 at 07:50:48PM +1030
Sender: owner-freebsd-questions@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Greg Lehey:
 |I don't see any important disadvantages in loadable kernel modules; in
 |fact, it's my preferred method of implementing additional
 |functionality.  Briefly,
 |
 |Pro:
 |
 |1.  LKMs are modular.  You can load them or not load them, and you
 |    don't need to rebuild the kernel to add their functionality.
 |
 |2.  You only need to have an LKM loaded when you want to run it.  If
 |    you want, you can unload it and reclaim the memory it occupies.
 |
 |3.  Starting the system can be faster, since you don't need to
 |    initalize the kernel version of the LKM.
 |
 |Con:
 |
 |1.  Although they're separate, LKMs are part of the kernel, and they
 |    must match the release.  If you try to run a 2.2.2 release LKM
 |    with release 2.2.5, you could have trouble, including panics, or
 |    it might not work at all.
 |
 |I'm sure there are more; if anybody wants to, feel free to add to this
 |list.

Another pro and con comes to mind:

Con: 

2. LKMs are currently unsuitable for drivers that need to allocate 
   large chunk(s) of physical memory.

   After a few seconds of OS time, memory is fragmented and
   vm_page_alloc_contig just doesn't work.  It doesn't seem to be able to swap 
   things out to free contig physical pages, but instead just hangs and 
   eats CPU.

   The Bt848 (bktr) driver is an example of such a driver (it allocates a
   3.5Meg frame buffer).

Sure do wish the bktr driver could be LKMized as it would make testing much
easier, which is the pro I had in mind:

Pro: 

4. Speeds up driver development and maintenance (don't have to reboot
   to test a change; just modunload, rebuild, modload).

Randall