From owner-freebsd-current Tue Jan 19 11:55:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA29984 for freebsd-current-outgoing; Tue, 19 Jan 1999 11:55:08 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA29976 for ; Tue, 19 Jan 1999 11:55:03 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by nlsystems.com (8.9.1/8.8.5) with SMTP id TAA47619; Tue, 19 Jan 1999 19:55:09 GMT Date: Tue, 19 Jan 1999 19:55:09 +0000 (GMT) From: Doug Rabson To: Peter Wemm cc: Julian Elischer , current@FreeBSD.ORG Subject: Re: KLD cannot load dependent modules In-Reply-To: <199901191121.TAA14881@spinner.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 > > > > 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