[PATCH] vt: configurable number of console devices

[PATCH] vt: configurable number of console devices

[Trevor Bourget]

Having 63 vt devices for embedded systems might be overkill,
so provide a configuration MAX_NR_CONSOLES to allow this
consumption to be reduced.

Signed-off-by: Trevor Bourget <tgb.kernel@gmail.com>
---
 drivers/tty/Kconfig     | 9 +++++++++
 include/uapi/linux/vt.h | 4 ++++
 2 files changed, 13 insertions(+)

diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index 3b1d312bb175..98e21589f4af 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -42,6 +42,15 @@ config VT
 	  If unsure, say Y, or else you won't be able to do much with your new
 	  shiny Linux system :-)
 
+config MAX_NR_CONSOLES
+	int "Maximum number of consoles to permit"
+	depends on VT
+	range 1 63
+	default "63"
+	---help---
+	  The maximum number of consoles that can be used.
+	  The default is 63.
+
 config CONSOLE_TRANSLATIONS
 	depends on VT
 	default y
diff --git a/include/uapi/linux/vt.h b/include/uapi/linux/vt.h
index e9d39c48520a..3567dd239758 100644
--- a/include/uapi/linux/vt.h
+++ b/include/uapi/linux/vt.h
@@ -8,9 +8,13 @@
  * resizing).
  */
 #define MIN_NR_CONSOLES 1       /* must be at least 1 */
+#ifdef CONFIG_MAX_NR_CONSOLES
+#define MAX_NR_CONSOLES CONFIG_MAX_NR_CONSOLES
+#else
 #define MAX_NR_CONSOLES	63	/* serial lines start at 64 */
 		/* Note: the ioctl VT_GETSTATE does not work for
 		   consoles 16 and higher (since it returns a short) */
+#endif
 
 /* 0x56 is 'V', to avoid collision with termios and kd */
 
-- 
2.22.0.rc1.257.g3120a18244-goog

Re: [PATCH] vt: configurable number of console devices

[Jiri Slaby]

On 28. 05. 19, 6:31, Trevor Bourget wrote:
> --- a/include/uapi/linux/vt.h
> +++ b/include/uapi/linux/vt.h
> @@ -8,9 +8,13 @@
>   * resizing).
>   */
>  #define MIN_NR_CONSOLES 1       /* must be at least 1 */
> +#ifdef CONFIG_MAX_NR_CONSOLES
> +#define MAX_NR_CONSOLES CONFIG_MAX_NR_CONSOLES

This is an uapi header. Will the #ifdef work there? As I don't think
CONFIG_* (i.e. autoconf.h) is available in userspace...

Also, I am not sure if there is any consumer of this macro in userspace
at all -- so what are the possible effects of this being "incorrect"?

BTW having headers from one kernel and booting another with different
settings makes this definition also incorrect. The same as for e.g. the
HZ constant. Again, not sure if this is a problem at all.

thanks,
-- 
js
suse labs

Re: [PATCH] vt: configurable number of console devices

[Trevor Bourget]

Sorry, I hadn't registered that was uapi. You are right, as a
configuration setting it's an odd thing to expose there.
That define won't really be any use to user space except for type
range validation, and as such it would actually be unhelpful for it to
be other than 63.

I will add if defined(__KERNEL__) to improve that, so that it will be
constant for uapi.

btw The idea is obviously not new. I can give credit to James Cox who
posted an actual patch 15 years ago that never merged.
https://lore.kernel.org/lkml/E1BFhPh-00027s-IL@smtp.gentoo.org/

-- Trevor

On Wed, May 29, 2019 at 4:03 AM Jiri Slaby <jslaby@suse.cz> wrote:
>
> On 28. 05. 19, 6:31, Trevor Bourget wrote:
> > --- a/include/uapi/linux/vt.h
> > +++ b/include/uapi/linux/vt.h
> > @@ -8,9 +8,13 @@
> >   * resizing).
> >   */
> >  #define MIN_NR_CONSOLES 1       /* must be at least 1 */
> > +#ifdef CONFIG_MAX_NR_CONSOLES
> > +#define MAX_NR_CONSOLES CONFIG_MAX_NR_CONSOLES
>
> This is an uapi header. Will the #ifdef work there? As I don't think
> CONFIG_* (i.e. autoconf.h) is available in userspace...
>
> Also, I am not sure if there is any consumer of this macro in userspace
> at all -- so what are the possible effects of this being "incorrect"?
>
> BTW having headers from one kernel and booting another with different
> settings makes this definition also incorrect. The same as for e.g. the
> HZ constant. Again, not sure if this is a problem at all.
>
> thanks,
> --
> js
> suse labs

Re: [PATCH] vt: configurable number of console devices

[Theodore Ts'o]

On Wed, May 29, 2019 at 03:09:11PM -0700, Trevor Bourget wrote:
> Sorry, I hadn't registered that was uapi. You are right, as a
> configuration setting it's an odd thing to expose there.
> That define won't really be any use to user space except for type
> range validation, and as such it would actually be unhelpful for it to
> be other than 63.
> 
> I will add if defined(__KERNEL__) to improve that, so that it will be
> constant for uapi.

It's by design that MAX_NR_CONSOLES is defined in a uapi header.
There are userspace programs that rely on this value (they use it to
declare arrays, so the version that we export to userspace MUST be
largest value that any kernel might support).

That being said, I've done an eyeball inspection to see how manytes
might be saved if we were to shirnk MAX_NR_CONSOLES, and... I don't
see that many bytes.  Maybe 24 bytes per console, so that maximum
savings would less than 1.5k?   Am I missing something?

Yes, we should all worry about kernel bloat; but it's not clear to me
this is a great place to start.  :-)

					- Ted