Date: Sat, 8 May 1999 17:45:43 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Peter Wemm <peter@netplex.com.au> Cc: cvs-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_linker.c kern_module.c src/sys/sys module.h Message-ID: <Pine.BSF.4.05.9905081743020.18703-100000@herring.nlsystems.com> In-Reply-To: <19990508163742.91AFA1F58@spinner.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 9 May 1999, Peter Wemm wrote: > Doug Rabson wrote: > > On Sat, 8 May 1999, Peter Wemm wrote: > > > > > > Modified files: > > > > sys/kern kern_linker.c kern_module.c > > > > sys/sys module.h > > > > Log: > > > > First stages of a module dependency cleanup. > > > > > > My plan is to have a module_set and probably dependency_set containing > > > solely a list of pointers to modules in files or module dependency and > > > version information. These will be a LOT easier to get to from the loader > > > than parsing the sysinit_set tables looking for module_register_init, and > > > should be reasonably easy to handle dependency information. > > > > Good idea. I wonder if it will be possible to write a userland tool which > > dlopens the kld file and reads out the module information. > > The interesting thing is that the dependency information can be defined in > pretty much the same way that DECLARE_MODULE() works. We don't need to > worry about data structures for linking dependencies to modules etc, > because all the information goes with the .o files. If they are linked > into a monolithic kernel, it's all merged into one set. If the same binary > is made into a kld, then the data is useable by the loader etc and is easy > to get to. The dependency info can probably specify filename hints too if > required. This all sounds very promising. > > FWIW, I see dependency information as a different mechanism to the new-bus > stuff. Exec handlers, VFS and misc kernel components, etc are not part of > the new-bus scheme at all. Absolutely. The module system was always intended to be separate from the device system, forming a foundation for loading and initialising drivers but also providing those same services to the kernel as a whole. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9905081743020.18703-100000>