In message <mtuhdaynbuo.fsf@contents-vnder-pressvre.mit.edu>, "Nathan J. Willia
ms" writes:
>Chuck Silvers <chuq@chuq.com> writes:
>
>> does anyone object to turning off DIAGNOSTIC in all the GENERIC configs?
>> this seems like reasonable anyway, and it fixes this issue in nicely.
>
>Why is this preferable to turning *on* DIAGNOSTIC in all the GENERIC
>configs?
>
>>  - these structures have an extra field if DIAGNOSTIC is on:
>> 
>> 	struct irframe_softc
>> 	struct usbd_xfer
>> 	struct wsemul_vt100_emuldata
>> 	struct cpu_data
>
>The one DIAGNOSTIC field in usbd_xfer is only accessed by the host
>controller driver (including allocation and deallocation), so its
>presence or absence just affects offsets. Would it be sufficent to
>move it to the end of the structure? Alternately, keeping 4 extra
>bytes on a 112-byte structure (on ILP32) isn't much to worry about.
>
>For the rest it seems pretty clear that the structures aren't numerous
>enough for size to be a big concern. It's probably worth marking that
>those members aren't filled with valid data if DIAGNOSTIC is off.
>

I think it's highly unlikely that the per-instance data structure 
overhead for DIAGNOSTIC is significant.  I'd suggest that as a design 
principle, data structure entries not be conditional, only sections of 
code.  I'd be astonished if the difference was more than a (very) few K 
bytes -- and even on the smallest platforms we support, that's not 
significant.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb