Change to kernel+modules build approach
Julian Elischer
julian at elischer.org
Fri Aug 15 11:52:05 PDT 2003
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"
>
More information about the freebsd-current
mailing list