cvs commit: src/sys/dev/lnc if_lnc.c

[M. Warner Losh]

In message: <20030722163007.GA6080 at HAL9000.homeunix.com>
            David Schultz <das at 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