Date: Tue, 22 Jul 2003 16:42:23 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: jhb@FreeBSD.org Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/lnc if_lnc.c Message-ID: <20030722.164223.00776481.imp@bsdimp.com> In-Reply-To: <XFMail.20030722175842.jhb@FreeBSD.org> References: <20030722.151828.83724752.imp@bsdimp.com> <XFMail.20030722175842.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <XFMail.20030722175842.jhb@FreeBSD.org>
John Baldwin <jhb@FreeBSD.org> writes:
:
: 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.
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.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030722.164223.00776481.imp>