cvs commit: src/sys/conf options src/sys/i386/acpica Makefile acpi_wakecode.S src/sys/i386/conf NOTES

[John Baldwin]

On 30-Oct-2003 Scott Long wrote:
> On Thu, 30 Oct 2003, M. Warner Losh wrote:
>> In message: <20031030102144.L89089 at root.org>
>>             Nate Lawson <nate at root.org> writes:
>> : On Wed, 29 Oct 2003, M. Warner Losh wrote:
>> : > In message: <20031029.232311.115991039.imp at bsdimp.com>
>> : >             M. Warner Losh <imp at bsdimp.com> writes:
>> : > : The "general silliness of compiling SMP for all modules" was a design
>> : > : decision for SMPng made a long time ago.  That's why there's no longer
>> : > : a SMP kernel option.
>> : >
>> : > Actually, I'm smoking crack here.  Forget I said it.
>> : >
>> : > We do, however, don't use the lock prefix on UP kernels.  Instead,
>> : > modules call the atomic functions, rather than inlining them.
>> :
>> : Whatever you smoke, the bounty is now up to $40, thanks to another donor.
>> : Let's see some code!
>>
>> I'll clean up what I have and commit it.
>>
>> Warner
>>
>>
> 
> Please, if you're going to do this, do it 100%.  Peter had some
> interesting ideas with unifying the building process of the kernel
> and modules and making the two basically indistinguishable.  This
> would likely get rid of the #ifdef KLD_MODULE hacks running around
> too.

KLD_MODULE needs to stay in some form.  The problem is how does
a 3rd party build a kernel module that works on all kernels (other than
the PAE case, which is a very special case IMO)

Basically, there are two different classes of modules that we need
(I think):

1) Modules optimized for a given kernel config.  These modules should
   be built during a kernel build, should _not_ have KLD_MODULE
   defined but should have access to all the normal config opt_foo
   headers.  They should also be built in the current directory of
   the kernel.  A module shouldn't be built if it is already compiled
   into the kernel.  In fact, the kernel config should actually list
   the modules with something like 'module wi' or some such.

   - The duplication of metadat between module Makefiles and
     sys/conf/files needs to stop.  I would prefer that we go
     with the sys/conf/files type approach, but it might need
     some tweaking to get right.

2) Modules that should "run everywhere".  3rd party vendors need this
   type of module.  This module should be built with KLD_MODULE defined.
   In fact, assuming you get 1) to actually work correctly, you could
   implement this by using a kernel config like so:

# config for module 'foo'

options         KLD_MODULE
module          foo

Possibly with an optional keyword to disable kernel building.  Though
that could be implemented by having config assume that it is only
compiling modules if there is no 'ident' keyword.

Howver, we need a plan with a known end destination that can be worked
towards, we shouldn't just blindly stumble around without a clear
direction of what we want out of our kernel modules system.

-- 

John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/