Date: Tue, 22 Jul 2003 17:58:42 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/lnc if_lnc.c Message-ID: <XFMail.20030722175842.jhb@FreeBSD.org> In-Reply-To: <20030722.151828.83724752.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22-Jul-2003 M. Warner Losh wrote:
> 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...
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@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20030722175842.jhb>