kern/59834: ucomvar.h in x86/consinit.c needs termios.h - not guaranteed

[kre%munnari.OZ.AU@localhost]

>Number:         59834
>Category:       kern
>Synopsis:       ucomvar.h in x86/consinit.c needs termios.h - not guaranteed
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Dec 13 10:15:00 +0000 2025
>Originator:     Robert Elz
>Release:        NetBSD 11.99.4
>Organization:
>Environment:
	
	
System: NetBSD jacaranda.noi.kre.to 11.99.4 NetBSD 11.99.4 (JACARANDA:1.1-20251124) #231: Mon Nov 24 20:19:24 +07 2025 kre%jacaranda.noi.kre.to@localhost:/usr/obj/testing/kernels/amd64/JACARANDA amd64
Architecture: x86_64
Machine: amd64
>Description:
	When the new ucom code was added, to allow USB devices to be
	the console (back at the end of last month - Nov 2025) an
	include of <dev/usb/ucomvar.h> was added to arch/x86/x86/consinit.c
	(& maybe to other places that don't affect me).

	ucomvar.h declares a function which takes a struct termios * as
	a parameter, but does not #include <sys/termios.h> - which can
	lead to x86/x86/consinit.c failing to compile.

	That isn't observed on most kernel builds, as x86/consinit.c
	includes <sys/termios.h> before including <dev/usb/ucomvar.h>
	in most builds - that is any which configure a com device.

	None of my recent hardware have any com devices at all, so
	I have deleted all "com* at <everything>" from my kernel
	config files.   That is, my (relevant) builds have NCOM==0

	In that case, <sys/termios.h> is not included in x86/consinit.c
	but (as I might one day plug in a USB com port device) I have
	ucom configured in (hence NUCOM > 0).

	gcc barfs:

In file included from .../src/sys/arch/x86/x86/consinit.c: 92:
 .../src/sys/dev/usb/ucomvar.h:83:47: error: 'struct termios' declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
   83 |         int (*ucom_param)(void *, int, struct termios *);
      |                                               ^~~~~~~
cc1: all warnings being treated as errors

	Note that the undefined use of struct termios * in
	<dev/usb/ucomvar.h> is not new - that has been there since
	the file was created, but obviously, until the end of last month,
	that file has only been included in contexts where <sys/termios.h>
	had already been included.

>How-To-Repeat:
	Configure an x86 kernel without any com devices, but with ucom.
	(As best I can tell, that's all it takes).

>Fix:
	First, for this particular case, on x86 where NCOM==0 and NUCOM>0
	I am testing a fix as I am typing this PR, so there is no need for
	anyone to do anything.

	There are several ways this could be fixed.

	1) The #include of <sys/termios.h> in consinit.c could be made
	   unconditional - clearly it is safe to include there, as it
	   almost always happens anyway.   However, consinit.c only uses
	   anything from that header if NCOM>0 (not struct termios, it
	   uses some of the symbols defined in <sys/termios.h> like CSIZE
	   SDTOPB PARENB ...) so fixing this that way doesn't seem like
	   the right solution to me.

	2) A second #include of <sys/termios.h> could be added to
	   consinit.c in the #if NUCOM>0 case, immediately before
	   the #include of <dev/usb/ucomvar.h>.   That would solve the
	   problem, and work (<sys/termios.h> has double-include protection,
	   so including it twice in the case where NCOM>0 and NUCOM>0
	   would be harmless).   However, to me this seems even worse than
	   possible solution #1 - in the case where it makes a difference,
	   absolutely nothing in consinit.c needs anything from termios.h
	   at all, so I don't think this one is the right solution either.

	3) <dev/usb/ucomvar.h> could have a #include <sys/termios.h>
	   added to it - after all, it is referencing struct termios,
	   so arguably that should have been done when the reference
	   was added, back in January 2000, when ucomvar.h was added
	   (the reference to struct termios was in rev 1.1).
	   However, all the header uses "struct termios" for is to
	   declare a parameter of one function as being a "struct termios *"
	   so this, while perhaps the technically correct solution,
	   looks to be rather heavyweight to me.

	4) <dev/usb/ucomvar.h> could have an incomplete type definition of
	   struct termios added to it - that allows the declaration of a
	   pointer to the struct, which is all that ucomvar.h needs.
	   This is the solution I prefer, and the one I have implemented
	   (and doing this allows my kernels to build, which is, of
	   course, what matters ... I expect doing any of the previous 3
	   methods would have accomplished the same goal, but I didn't
	   test them.

	I will (immediately after this PR has cycled through gnats -
	my test builds succeeded while I have been typing this)
	be committing the fix I have used (#4 above).   If anyone has
	the desire (and energy to test) any other solution (one of
	the others above, or something different), please go ahead.

	If there is any possibility of something similar affecting
	any of the other ports, someone else is going to need to
	go and fix it (though unless something very odd has happened,
	it is likely that the fix about to be committed should work
	everywhere - anything that needs to actually use a struct termios
	should already be including <sys/termios.h> - the incomplete
	type definition in <dev/usb/ucomvar.h> would then be completed.

>Unformatted: