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" >Received on Fri Aug 15 2003 - 09:52:05 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:18 UTC