Date: Thu, 30 Oct 2003 14:39:06 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Scott Long <scottl@freebsd.org> Cc: nate@root.org Subject: Re: cvs commit: src/sys/conf options src/sys/i386/acpica Makefile acpi_wakecode.S src/sys/i386/conf NOTES Message-ID: <XFMail.20031030143906.jhb@FreeBSD.org> In-Reply-To: <20031030122318.J11750@pooker.samsco.home>
next in thread | previous in thread | raw e-mail | index | archive | help
On 30-Oct-2003 Scott Long wrote:
> On Thu, 30 Oct 2003, M. Warner Losh wrote:
>> In message: <20031030102144.L89089@root.org>
>> Nate Lawson <nate@root.org> writes:
>> : On Wed, 29 Oct 2003, M. Warner Losh wrote:
>> : > In message: <20031029.232311.115991039.imp@bsdimp.com>
>> : > M. Warner Losh <imp@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@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20031030143906.jhb>