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

[John Baldwin]

On 22-Jul-2003 M. Warner Losh wrote:
> 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...

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 <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/