Date: Tue, 22 Jul 2003 15:18:28 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: das@freebsd.org Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/lnc if_lnc.c Message-ID: <20030722.151828.83724752.imp@bsdimp.com> In-Reply-To: <20030722163007.GA6080@HAL9000.homeunix.com> References: <20030722235600.X8165@gamplex.bde.org> <11951.1058884091@critter.freebsd.dk> <20030722163007.GA6080@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20030722163007.GA6080@HAL9000.homeunix.com>
David Schultz <das@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030722.151828.83724752.imp>