Subject: Re: PR 31468 -- distributed LKMs are not useful because of incompatible config
To: Chuck Silvers <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 10/31/2005 14:46:50
Content-Type: text/plain; charset=us-ascii
On Sun, Oct 30, 2005 at 09:04:56AM -0800, Chuck Silvers wrote:
> does anyone object to turning off DIAGNOSTIC in all the GENERIC configs?
> this seems like reasonable anyway, and it fixes this issue in nicely.
As a direct answer to your question, I think it may be best to leave it on=
for -current kernels and to turn it off for release kernels.
I think though we are muddling three issues in this thread:
1) Should DIAGNOSTIC be on in GENERIC kernels (my answer's above, but I
don't feel very strongly about this)?
2) Should our default shipping LKMs have options that differ from our
default shipping kernels?
3) Should DIAGNOSTIC make LKMs incompatible?
I agree with you that I think the answer to #3 should be no, and support=20
your efforts to change this. :-)
However I think we really need to fix #2; while getting rid of DIAGNOSTIC=
gets rid of the pain, the issue is still there. Also, I don't think the=20
fix is that hard. :-)
All I think we need to do is add a make variable, say KMOD_KERNCONFOPTS,=20
conditionally set it in bsd.kmod.mk, and always add the variable to=20
CPPFLAGS and CFLAGS (and anything else that needs it).
We then just make sure that the conditional define matches GENERIC and=20
> in the longer term, I think that DIAGNOSTIC should not make LKMs incompat=
> I checked the source tree for reasons why turning on this option might ca=
> incompatibilities, and I found just a few things:
> - these structures have an extra field if DIAGNOSTIC is on:
> struct irframe_softc
> struct usbd_xfer
> struct wsemul_vt100_emuldata
> struct cpu_data
> struct ehci_xfer
> struct ohci_soft_itd
> struct uhci_intr_info
> struct union_node
> I'm guessing that structures in the first group are significant for LK=
> whereas those the second group are not.
> I think that for structures in the first group we should either have
> these fields always present, or just remove them and the code that
> references them. It would be nice to do that for the second group
> as well, just so that it's easier to make sure we don't add more things
> to the first group in the future.
I'd say make the data always present.
> - these headers define functions as inline iff !DIAGNOSTIC
> I think we should just make these not be inline.
Maybe make them a separate inline control, like we have for VOPs? I=20
thought inlining was faster for some cases.. ??
> any objections to these longer-term changes?
No. Comments & thoughs as above, but no objections.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----