From owner-cvs-src@FreeBSD.ORG Tue Jul 22 14:18:46 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 68B2837B401; Tue, 22 Jul 2003 14:18:46 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B84B43FB1; Tue, 22 Jul 2003 14:18:45 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9/8.12.3) with ESMTP id h6MLIZFL051755; Tue, 22 Jul 2003 15:18:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 22 Jul 2003 15:18:28 -0600 (MDT) Message-Id: <20030722.151828.83724752.imp@bsdimp.com> To: das@freebsd.org From: "M. Warner Losh" In-Reply-To: <20030722163007.GA6080@HAL9000.homeunix.com> References: <20030722235600.X8165@gamplex.bde.org> <11951.1058884091@critter.freebsd.dk> <20030722163007.GA6080@HAL9000.homeunix.com> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: 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:18:46 -0000 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... Warner