Change to kernel+modules build approach

[Julian Elischer]

On Fri, 15 Aug 2003, M. Warner Losh wrote:

> In message: <16189.7417.798216.977283 at grasshopper.cs.duke.edu>
>             Andrew Gallatin <gallatin at cs.duke.edu> writes:
> : 
> : John Baldwin writes:
> :  > 
> :  > No, generic modules would always work with all kernels except for
> :  > exceptional cases like PAE (unavoidable, really), and MUTEX_PROFILING
> :  > (this is a debugging thing, so ISV's wouldn't need to ship modules
> :  > with that turned on).  All this would add is the ability to build
> :  > modules optimized for your current kernel.  If this is not super
> :  > desired (which I wouldn't mind), then I think we should take the
> :  > modules out of /boot/kernel and put them in /boot/modules or some such.
> :  > I do want to get the metadata down to one copy somehow though.
> : 
> : YES!  YES!  I'd be very much in favor of totally decoupling the
> : modules from the kernel.
> : 
> : In fact, once we've done that, we can move the kernel back to /kernel
> : where it belongs, and /boot/modules can become /modules  ;)
> 
> That would be somewhat difficult.  It would make it a lot harder to
> keep a 2 or 4 week old kernel around for testing since you couldn't
> load current modules with an old kernel (generally, but sometimes it
> works).

Has anyone in this discussion looked at what Matt has done with
Dragonfly? He's re-arranged the kernel tree and moved each driver/module
into its own directory. Each directory has a Makefile. thus 
a traversal of the kernel tree "make" hierarchy generates the modules.

The "modules" subdirectory is going away.. (I think he's in the middle
of doing that now)




> 
> Warner
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>