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

[John Baldwin]

On 22-Jul-2003 M. Warner Losh wrote:
> In message: <XFMail.20030722175842.jhb at FreeBSD.org>
>             John Baldwin <jhb at FreeBSD.org> writes:
>: 
>: 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.
> 
> I tried playing with that, but it is also a hard problem.  You then
> have strong ordering issues, which makes it hard to unload pccard and
> reload it w/o unloading all things that depend on it.
> 
> Eg, I don't want to have to unload the if_wi_pccard driver when I want
> to unload and reload pccard.ko.

Umm, you should be having to unload if_wi then when unloading pccard.
If if_wi tries to call a pccard method on an attached pccard device
after pccard is unloaded, I'm sure lots of things are going to break.
Hmmm.  I guess if unloading pccard detaches all pccard devices and their
children then it is safe if you always use KOBJ methods and never link
against any functions for your bus attachments.

-- 

John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/