Date: Tue, 19 Jan 1999 19:55:09 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Peter Wemm <peter@netplex.com.au> Cc: Julian Elischer <julian@whistle.com>, current@FreeBSD.ORG Subject: Re: KLD cannot load dependent modules Message-ID: <Pine.BSF.4.01.9901191953590.47597-100000@herring.nlsystems.com> In-Reply-To: <199901191121.TAA14881@spinner.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 19 Jan 1999, Peter Wemm wrote: > Doug Rabson wrote: > > On Tue, 19 Jan 1999, Julian Elischer wrote: > > > > > > > > If I load a module A > > > then try load a module B that requires a function in A > > > it fails because it cannot find the symbol.. > > > is this a known problem? > > > > > > (A real bummer if so) > > > > The module B needs to have A as a dependancy. Use KMODDEPS to do this. > > Something like this should work in the Makefile: > > > > KMOD= modB > > SRCS= ... > > KMODDEPS= modA > > KLDMOD=t > > NOMAN=t > > .include <bsd.kmod.mk> > > > > The linker will only resolve symbols against the files in the dependancy > > list (and the kernel). > > I've been thinking that this could be improved. Yes, following the > dependency list first for resolving symbols is right, I think there should > be a fallback global search. > > Specific example (which is probably going to change today, but it's a good > example): > > - wd.c has got hooks for the ATAPI code. > - The ATAPI code can be build either statically or as a module. > - ATAPI clients (acd, wfd, wst etc) therefore depend either on the kernel or > the atapi module. If the atapi module was statically configured, and the > acd driver depended on the atapi file, it would eventually fail due to > conflicts. > - However, if the acd driver didn't depend on atapi (the file), then a > kernel compiled without it would be unable to load acd.ko regardless of > whether atapi.ko had been previously loaded, because acd.ko won't see the > symbold in atapi.ko. > > Does this description of the problem make sense? I think the symbol > resolution should do a global search once the dependency list is exhausted. This makes a lot of sense. I think this is what Mike is trying to address in his new module-based instead of file-based dependancy scheme. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" 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.01.9901191953590.47597-100000>