vt: Add boot param for setting default vt console

Presently the default console is hard-coded to vt1.

The param allows for setting a different default. The param defaults to 0 (vt1), preserving the current behavior. It is clamped by the constants (MIN|MAX)_NR_CONSOLES. If set >= MIN, con_init will initialize that vt as well (a couple extra kilobytes heap for the vc_data and vc_screenbuf structs).

Without this feature, users achieve the same effect with an init script[0][1][2][3]. This works but requires an extra chvt(1) which can race with user interaction and flicker the screen at login.

[0]: https://bbs.archlinux.org/viewtopic.php?id=232058
[1]: https://unix.stackexchange.com/questions/399986
[2]: https://github.com/systemd/systemd/issues/7247
[3]: https://www.linuxquestions.org/questions/linux-general-1/x-4175722418

---
 .../admin-guide/kernel-parameters.txt         |  5 +++
 drivers/tty/vt/vt.c                           | 44 +++++++++++++------
 2 files changed, 36 insertions(+), 13 deletions(-)

index cb850e5290c2..6694b2edcfd6 100644
@@ -8429,6 +8429,11 @@ Kernel parameters
 			overridden by individual drivers. 0 will hide
 			cursors, 1 will display them.
 
+	vt.default_console=
+			[VT]
+			Set default console; 0-62.
+			Default: 0 (vt1)
+
 	vt.italic=	[VT] Default color for italic text; 0-15.
 			Default: 2 = green.
 

2.51.0

What user interaction races? I'm loath to change this as I've not seen any bug reports for this. What changed to cause this issue?

And this is for the "odd" systems that want a graphical login, BUT still want to default to the console? That's a very odd configuration, and I think that we should just stick with the fix that we have for those that want to do this as adding more boot parameters that we need to support for forever feels like a bad idea.

sorry,

greg k-h