From owner-cvs-src@FreeBSD.ORG Tue Jul 22 14:58:36 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 105CE37B404 for ; Tue, 22 Jul 2003 14:58:36 -0700 (PDT) Received: from mail.speakeasy.net (mail16.speakeasy.net [216.254.0.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5BE443FBD for ; Tue, 22 Jul 2003 14:58:33 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 26222 invoked from network); 22 Jul 2003 21:58:32 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 22 Jul 2003 21:58:32 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h6MLwPGI043549; Tue, 22 Jul 2003 17:58:27 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030722.151828.83724752.imp@bsdimp.com> Date: Tue, 22 Jul 2003 17:58:42 -0400 (EDT) From: John Baldwin To: "M. Warner Losh" cc: phk@phk.freebsd.dk cc: src-committers@freebsd.org cc: bde@zeta.org.au cc: paul@freebsd-services.com cc: cvs-src@freebsd.org cc: das@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/lnc if_lnc.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2003 21:58:36 -0000 On 22-Jul-2003 M. Warner Losh wrote: > In message: <20030722163007.GA6080@HAL9000.homeunix.com> > David Schultz writes: >: There is reason for concern about cases where inline really is >: misused, either because it massively increases code size or >: because it is unimportant to performance and detracts from >: debuggability. But I would not like to see a policy that shifts >: the burden of proof onto authors of new code.[1] A policy about >: gratuitous sweeps through other people's code, on the other >: hand... > > There's one other place that we use inlining. We use it to make sure > that modules do not contain references to certain symbols. For > example: > > /* > * make this inline so that we don't have to worry about dangling references > * to it in the modules or the code. > */ > static __inline const struct pccard_product * > pccard_product_lookup(device_t dev, const struct pccard_product *tab, > size_t ent_size, pccard_product_match_fn matchfn) > { > return CARD_DO_PRODUCT_LOOKUP(device_get_parent(dev), dev, > tab, ent_size, matchfn); > } > > We do this to get the type safty of the function call and not have to > make that a macro. We do *NOT* want references to > pccard_product_lookup, but the CARD_DO_.. kobj call allows the > indirection that makes it possible to use the same module in kernels > with and without pccard support. > > This isn't either of the performance or size trade-offs. It is a > design decision to use inline over #define. If the new gcc breaks > this, then it becomes a #define... I think that this is a bandaid solution though. Ideally if you load a device driver, it really contains several modules: one base module for the base code and one module for each bus attachment. The base attachment must link for the load to complete, but if a bus attachment doesn't link due to missing symbols because that bus isn't present in the kernel, it's not an error. At least that's how I think it should work. The acpi module already has this issue now that it calls pci and isa functions. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/