On 15-Aug-2003 M. Warner Losh wrote: > In message: <XFMail.20030814135816.jhb_at_FreeBSD.org> > John Baldwin <jhb_at_freebsd.org> writes: >: >: On 14-Aug-2003 Andrew Gallatin wrote: >: > >: > John Baldwin writes: >: > > >: > > On 14-Aug-2003 Ruslan Ermilov wrote: >: > > > On Thu, Aug 14, 2003 at 02:10:19AM -0600, Scott Long wrote: >: > > >> Luoqi Chen wrote: >: > > > [...] >: > > >> >On the other hand, all modules should create all the opt_*.h files >: > > >> >it needs when built individually. Add opt_ddb.h to nullfs's Makefile >: > > >> >should fix the breakage. >: > > >> > >: > > >> Our kernel build system isn't set up to handle passing config options >: > > >> to modules. Various solutions to this have been proposed, but nothing >: > > >> has appeared yet. In 5.x, we document that modules will not work with >: > > >> PAE. >: > > >> >: > > > How does the below look? This is basically a more generic implementation >: > > > of Luoqi's idea, but for -CURRENT: >: > > >: > > I would prefer something far more radical that would involve moving >: > > all the module metadata to sys/conf (i.e. removing sys/modules) and >: > > building all the modules based on a single kernel config file. >: > >: > Would this tie modules to that kernel config? If so, would it mean >: > the end of the ability of 3rd party developers to ship binary drivers >: > and expect them to work with any kernel? >: >: Well, yes, but, one could always build generic modules by using >: a kernel config containing 'options KLD_MODULE' or some such. >: This would allow one to compile optimized modules if they wanted to, >: but still provide the ability to build fully generic modules. > > This sounds like an either or choice. I don't care too much if the > third party drivers aren't hyper optimzied for my kernel. But to > force users of them to use some generic kernel would be a big support > nightmare. 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. -- John Baldwin <jhb_at_FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/Received on Fri Aug 15 2003 - 08:40:10 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:18 UTC