--rwEMma7ioTxnRzrJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Oct 30, 2005 at 09:04:56AM -0800, Chuck Silvers wrote:
> hi,
>=20
> 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=
=20
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=
=20
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
we're set!

> in the longer term, I think that DIAGNOSTIC should not make LKMs incompat=
ible.
> I checked the source tree for reasons why turning on this option might ca=
use
> incompatibilities, and I found just a few things:
>=20
>  - these structures have an extra field if DIAGNOSTIC is on:
>=20
> 	struct irframe_softc
> 	struct usbd_xfer
> 	struct wsemul_vt100_emuldata
> 	struct cpu_data
>=20
> 	struct ehci_xfer
> 	struct ohci_soft_itd
> 	struct uhci_intr_info
> 	struct union_node
>=20
>=20
>    I'm guessing that structures in the first group are significant for LK=
Ms
>    whereas those the second group are not.
>=20
>    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
> 	sys/vnode.h
> 		holdrelel
> 		vholdl
> 		vref
>=20
>    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.

Take care,

Bill

--rwEMma7ioTxnRzrJ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFDZp7ZWz+3JHUci9cRAkDeAJ9isyFu9U0PEiZ2NlHZJdSe1TvMGACfahB/
5Nm8c8q7ZCNiQ/ml9AunscY=
=BQ4q
-----END PGP SIGNATURE-----

--rwEMma7ioTxnRzrJ--