Date: Tue, 19 Jan 1999 19:21:53 +0800 From: Peter Wemm <peter@netplex.com.au> To: Doug Rabson <dfr@nlsystems.com> Cc: Julian Elischer <julian@whistle.com>, current@FreeBSD.ORG Subject: Re: KLD cannot load dependent modules Message-ID: <199901191121.TAA14881@spinner.netplex.com.au> In-Reply-To: Your message of "Tue, 19 Jan 1999 09:37:48 GMT." <Pine.BSF.4.01.9901190933530.40696-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Cheers, -Peter 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?199901191121.TAA14881>