[PATCH] Add possibility to set /dev/tty number

[PATCH] Add possibility to set /dev/tty number

[Pierre Paul MINGOT]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

Hello,

In Linux there is no way to set the number of tty devices or console
to create. By default the kernel create 64 /dev/tty devices. what is
too much for embedded system with limited resources. As all these 64
devices are not necessary or mandatory for the kernel proper working,
I add a config option to set the desired tty. The lowest number you
can set is 1 and the highest is 63, any value respectively below or
above that, will cause a kconfig invalid entry pop-up.

Please keep me update.

Best Regards

[-- Attachment #2: 0001-In-Linux-there-is-no-way-to-set-the-number-of-tty-de.patch --]
[-- Type: text/x-patch, Size: 2434 bytes --]

From 430deaf09da90bf0da03b7ca612cd4481ad30fea Mon Sep 17 00:00:00 2001
From: Pierre Paul MINGOT <mingot.pierre@gmail.com>
Date: Thu, 22 Jan 2015 17:51:49 +0100
Subject: [PATCH] In Linux there is no way to set the number of tty devices or
 console to create. By default the kernel create 64 /dev/tty devices. what is
 too much for embedded system with limited resources. As all these 64 devices
 are not necessary or mandatory for the kernel proper working, I add a config
 option to set the desired tty. The lowest number you can set is 1 and the
 highest is 63, any value respectively below or above that, will cause a
 kconfig invalid entry pop-up.

Signed-off-by: Pierre Paul MINGOT <mingot.pierre@gmail.com>
---
 drivers/tty/Kconfig     | 14 ++++++++++++++
 include/uapi/linux/vt.h |  4 ++--
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index b24aa01..0ec58a2 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -75,6 +75,19 @@ config VT_CONSOLE_SLEEP
 	def_bool y
 	depends on VT_CONSOLE && PM_SLEEP
 
+config NR_TTY_DEVICES
+    int "Maximum tty device number"
+    depends on VT
+    range 1 63
+    default 1
+    ---help---
+    This is the highest numbered device created in /dev. You will actually have
+	NR_TTY_DEVICES+1 devices in /dev. The default is 63, which will result in
+	64 /dev entries. The lowest number you can set is 1 and the highest is 63,
+    anything respectively below or above that, is not possible and will cause
+    a kconfig invalid entry pop-up.
+    So the default value will be set.
+
 config HW_CONSOLE
 	bool
 	depends on VT && !UML
@@ -419,4 +432,5 @@ config DA_CONSOLE
 	help
 	  This enables a console on a Dash channel.
 
+
 endif # TTY
diff --git a/include/uapi/linux/vt.h b/include/uapi/linux/vt.h
index 978578b..2140496 100644
--- a/include/uapi/linux/vt.h
+++ b/include/uapi/linux/vt.h
@@ -7,8 +7,8 @@
  * resizing).
  */
 #define MIN_NR_CONSOLES 1       /* must be at least 1 */
-#define MAX_NR_CONSOLES	63	/* serial lines start at 64 */
-#define MAX_NR_USER_CONSOLES 63	/* must be root to allocate above this */
+/* serial lines start at 64 */
+#define MAX_NR_CONSOLES	 CONFIG_NR_TTY_DEVICES
+/* must be root to allocate above this */
+#define MAX_NR_USER_CONSOLES CONFIG_NR_TTY_DEVICES
 		/* Note: the ioctl VT_GETSTATE does not work for
 		   consoles 16 and higher (since it returns a short) */
 
-- 
1.9.1

Re: [PATCH] Add possibility to set /dev/tty number

[Greg KH]

On Mon, Jan 04, 2016 at 04:34:56PM +0100, Pierre Paul MINGOT wrote:
> Hello,
> 
> In Linux there is no way to set the number of tty devices or console
> to create. By default the kernel create 64 /dev/tty devices. what is
> too much for embedded system with limited resources.

Really?  How much memory does a vt device take up?

> As all these 64
> devices are not necessary or mandatory for the kernel proper working,
> I add a config option to set the desired tty. The lowest number you
> can set is 1 and the highest is 63, any value respectively below or
> above that, will cause a kconfig invalid entry pop-up.
> 
> Please keep me update.

Please don't attach patches, I can't do anything with them, you should
include them directly in your email.  Also, if you look at your patch:

> From 430deaf09da90bf0da03b7ca612cd4481ad30fea Mon Sep 17 00:00:00 2001
> From: Pierre Paul MINGOT <mingot.pierre@gmail.com>
> Date: Thu, 22 Jan 2015 17:51:49 +0100
> Subject: [PATCH] In Linux there is no way to set the number of tty devices or
>  console to create. By default the kernel create 64 /dev/tty devices. what is
>  too much for embedded system with limited resources. As all these 64 devices
>  are not necessary or mandatory for the kernel proper working, I add a config
>  option to set the desired tty. The lowest number you can set is 1 and the
>  highest is 63, any value respectively below or above that, will cause a
>  kconfig invalid entry pop-up.

The entire changelog entry is in the Subject, which I doubt is what you
want :(

Please fix it up to have a short subject first and resend, after fixing
the errors below as well:

> diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
> index b24aa01..0ec58a2 100644
> --- a/drivers/tty/Kconfig
> +++ b/drivers/tty/Kconfig
> @@ -75,6 +75,19 @@ config VT_CONSOLE_SLEEP
>  	def_bool y
>  	depends on VT_CONSOLE && PM_SLEEP
>  
> +config NR_TTY_DEVICES
> +    int "Maximum tty device number"
> +    depends on VT
> +    range 1 63
> +    default 1
> +    ---help---
> +    This is the highest numbered device created in /dev. You will actually have
> +	NR_TTY_DEVICES+1 devices in /dev. The default is 63, which will result in
> +	64 /dev entries. The lowest number you can set is 1 and the highest is 63,
> +    anything respectively below or above that, is not possible and will cause
> +    a kconfig invalid entry pop-up.
> +    So the default value will be set.
> +

Odd mixture of tabs and spaces, just always use tabs please.

And the default should not be 1, keep it what it is today.

>  config HW_CONSOLE
>  	bool
>  	depends on VT && !UML
> @@ -419,4 +432,5 @@ config DA_CONSOLE
>  	help
>  	  This enables a console on a Dash channel.
>  
> +
>  endif # TTY
> diff --git a/include/uapi/linux/vt.h b/include/uapi/linux/vt.h
> index 978578b..2140496 100644
> --- a/include/uapi/linux/vt.h
> +++ b/include/uapi/linux/vt.h
> @@ -7,8 +7,8 @@
>   * resizing).
>   */
>  #define MIN_NR_CONSOLES 1       /* must be at least 1 */
> -#define MAX_NR_CONSOLES	63	/* serial lines start at 64 */
> -#define MAX_NR_USER_CONSOLES 63	/* must be root to allocate above this */
> +/* serial lines start at 64 */

This doesn't make sense anymore, right?

Are you breaking the serial line minor number with this change?

thanks,

greg k-h

Re: [PATCH] Add possibility to set /dev/tty number

[Austin S. Hemmelgarn]

On 2016-01-04 10:43, Greg KH wrote:
> On Mon, Jan 04, 2016 at 04:34:56PM +0100, Pierre Paul MINGOT wrote:
>> Hello,
>>
>> In Linux there is no way to set the number of tty devices or console
>> to create. By default the kernel create 64 /dev/tty devices. what is
>> too much for embedded system with limited resources.
>
> Really?  How much memory does a vt device take up?
On a device with a simple text mode console in 80x25, a minimum of 2000 
bytes, not including anything used for character attributes, and 
anything else needed for the display and updating of the screen (I think 
I worked out once that it comes out to about 8k).  On my laptop which 
has a 1920x1080 screen, using the standard 8x16 VGA font with a 
framebuffer console via i915, I get a 200x67 terminal size, which means 
that just the text without any attributes works out to a little more 
than 13k.  That gets doubled just by adding color, and probably doubled 
again for the other display attributes.  All of this also doesn't factor 
in the space taken up in devtmpfs and sysfs by the associated files 
(it's not much, but it's still wasted space).

That said, there are factors to consider other than just memory footprint:
1. Having 64 tty devices in /dev leads to somewhat cluttered listings 
(on most small systems I see, more than two thirds of the contents of 
/dev are tty device nodes).
2. Most people don't know how to switch to anything higher than about 
tty 15, a majority of people who have a graphical environment use at 
most 2 VT's, and a lot of embedded systems use a fixed number of VT's 
that is known prior to full production.
3. There is some very poorly designed software out there (at least the 
original version of ConsoleKit, and I'd be willing to bet some 
third-party vendor software) which unconditionally starts a thread or 
process for each VT in the system.  While this software should be fixed 
to behave properly, it's infeasible for most end users to do this.

Re: [PATCH] Add possibility to set /dev/tty number

[Greg KH]

On Mon, Jan 04, 2016 at 11:57:33AM -0500, Austin S. Hemmelgarn wrote:
> On 2016-01-04 10:43, Greg KH wrote:
> >On Mon, Jan 04, 2016 at 04:34:56PM +0100, Pierre Paul MINGOT wrote:
> >>Hello,
> >>
> >>In Linux there is no way to set the number of tty devices or console
> >>to create. By default the kernel create 64 /dev/tty devices. what is
> >>too much for embedded system with limited resources.
> >
> >Really?  How much memory does a vt device take up?
> On a device with a simple text mode console in 80x25, a minimum of 2000
> bytes, not including anything used for character attributes, and anything
> else needed for the display and updating of the screen (I think I worked out
> once that it comes out to about 8k).  On my laptop which has a 1920x1080
> screen, using the standard 8x16 VGA font with a framebuffer console via
> i915, I get a 200x67 terminal size, which means that just the text without
> any attributes works out to a little more than 13k.  That gets doubled just
> by adding color, and probably doubled again for the other display
> attributes.  All of this also doesn't factor in the space taken up in
> devtmpfs and sysfs by the associated files (it's not much, but it's still
> wasted space).

If the console isn't initialized by userspace, is any of that space
still really being used?  Have you tried that?

> That said, there are factors to consider other than just memory footprint:
> 1. Having 64 tty devices in /dev leads to somewhat cluttered listings (on
> most small systems I see, more than two thirds of the contents of /dev are
> tty device nodes).

Not having a cluttered /dev isn't the best reasoning here :)

> 2. Most people don't know how to switch to anything higher than about tty
> 15, a majority of people who have a graphical environment use at most 2
> VT's, and a lot of embedded systems use a fixed number of VT's that is known
> prior to full production.

Agreed, but does this actually take up memory?

> 3. There is some very poorly designed software out there (at least the
> original version of ConsoleKit, and I'd be willing to bet some third-party
> vendor software) which unconditionally starts a thread or process for each
> VT in the system.  While this software should be fixed to behave properly,
> it's infeasible for most end users to do this.

If we remove the number of devices, those "broken" userspace programs
will also break, so that implies that we should not allow this change.

Please provide some "real" numbers of memory savings please before
saying that this change really does save memory.  Just guessing isn't
ok.

thanks,

greg k-h

Re: [PATCH] Add possibility to set /dev/tty number

[Austin S. Hemmelgarn]

On 2016-01-04 12:11, Greg KH wrote:
> On Mon, Jan 04, 2016 at 11:57:33AM -0500, Austin S. Hemmelgarn wrote:
>> On 2016-01-04 10:43, Greg KH wrote:
>>> On Mon, Jan 04, 2016 at 04:34:56PM +0100, Pierre Paul MINGOT wrote:
>>>> Hello,
>>>>
>>>> In Linux there is no way to set the number of tty devices or console
>>>> to create. By default the kernel create 64 /dev/tty devices. what is
>>>> too much for embedded system with limited resources.
>>>
>>> Really?  How much memory does a vt device take up?
>> On a device with a simple text mode console in 80x25, a minimum of 2000
>> bytes, not including anything used for character attributes, and anything
>> else needed for the display and updating of the screen (I think I worked out
>> once that it comes out to about 8k).  On my laptop which has a 1920x1080
>> screen, using the standard 8x16 VGA font with a framebuffer console via
>> i915, I get a 200x67 terminal size, which means that just the text without
>> any attributes works out to a little more than 13k.  That gets doubled just
>> by adding color, and probably doubled again for the other display
>> attributes.  All of this also doesn't factor in the space taken up in
>> devtmpfs and sysfs by the associated files (it's not much, but it's still
>> wasted space).
>
> If the console isn't initialized by userspace, is any of that space
> still really being used?  Have you tried that?
I'm pretty certain that most of the space that gets taken up by the 
scrollback buffer and screen isn't directly used unless the console is 
used, but there are still structures that get allocated at driver 
instantiation for each VT, including the device structures and such.
>
>> That said, there are factors to consider other than just memory footprint:
>> 1. Having 64 tty devices in /dev leads to somewhat cluttered listings (on
>> most small systems I see, more than two thirds of the contents of /dev are
>> tty device nodes).
>
> Not having a cluttered /dev isn't the best reasoning here :)
It wasn't intended as an argument on it's own, simply an additional 
point.  It does have an impact though if you're dealing with something 
like a slow serial console, and it also looks _really_ odd having a 
bunch of device nodes for virtual devices that aren't used, and on most 
systems you can't get rid of at runtime (I've always been under the 
impression that having a dynamic /dev was primarily to avoid all the 
clutter you see there on systems like BSD (most derivatives of which 
still use a statically initialized /dev)).
>
>> 2. Most people don't know how to switch to anything higher than about tty
>> 15, a majority of people who have a graphical environment use at most 2
>> VT's, and a lot of embedded systems use a fixed number of VT's that is known
>> prior to full production.
>
> Agreed, but does this actually take up memory?
My point here was more that high numbered VT's are something that's 
pretty much unused on most systems, and therefore there is almost zero 
benefit for a majority of people.  At the very least it takes up space 
for the driver internal structures, and the stuff in sysfs.  While a few 
Kb of memory may not seem like much given that servers with close to 1Tb 
of RAM are starting to become common, it can still make a lot of 
difference in performance for a small embedded system.
>
>> 3. There is some very poorly designed software out there (at least the
>> original version of ConsoleKit, and I'd be willing to bet some third-party
>> vendor software) which unconditionally starts a thread or process for each
>> VT in the system.  While this software should be fixed to behave properly,
>> it's infeasible for most end users to do this.
>
> If we remove the number of devices, those "broken" userspace programs
> will also break, so that implies that we should not allow this change.
No, the software should just need to be recompiled (I've tested this 
with ConsoleKit, which also fails gracefully when it tires to open a tty 
device that doesn't exist), or adapted to dynamically detect the number 
of TTYs (like it should have in the first place for portability reasons).
>
> Please provide some "real" numbers of memory savings please before
> saying that this change really does save memory.  Just guessing isn't
> ok.
I can probably put something together to actually test this, but it will 
take a while (most of my testing scripts and VM's are targeted at 
regression testing of filesystems, not memory profiling of virtual 
device drivers). I doubt that it will work out to any more than 16k size 
difference, but that's still a few more pages (on most systems) that 
could be used for other things.

Re: [PATCH] Add possibility to set /dev/tty number

[One Thousand Gnomes]

> > If the console isn't initialized by userspace, is any of that space
> > still really being used?  Have you tried that?
> I'm pretty certain that most of the space that gets taken up by the 
> scrollback buffer and screen isn't directly used unless the console is 
> used, but there are still structures that get allocated at driver 
> instantiation for each VT, including the device structures and such.

So fix that instead.

And really for low memory embedded why do you even have the VT layer in
your system in the first place ?

> > If we remove the number of devices, those "broken" userspace programs
> > will also break, so that implies that we should not allow this change.
> No, the software should just need to be recompiled (I've tested this 
> with ConsoleKit, which also fails gracefully when it tires to open a tty 
> device that doesn't exist), or adapted to dynamically detect the number 
> of TTYs (like it should have in the first place for portability reasons).

We don't do regressions.

> device drivers). I doubt that it will work out to any more than 16k size 
> difference, but that's still a few more pages (on most systems) that 
> could be used for other things.

And those embedded devices can almost certainly save more by just not
including the vt layer.

Alan

Re: [PATCH] Add possibility to set /dev/tty number

[Austin S. Hemmelgarn]

On 2016-01-04 17:55, One Thousand Gnomes wrote:
>>> If the console isn't initialized by userspace, is any of that space
>>> still really being used?  Have you tried that?
>> I'm pretty certain that most of the space that gets taken up by the
>> scrollback buffer and screen isn't directly used unless the console is
>> used, but there are still structures that get allocated at driver
>> instantiation for each VT, including the device structures and such.
>
> So fix that instead.
I never said that it was broken, I was just pointing out that the 
overhead is non-zero even when the VT is unused.
>
> And really for low memory embedded why do you even have the VT layer in
> your system in the first place ?
Sometimes this is unavoidable.  Any kind of generic system generally 
wants the VT layer, and there are a number of low memory embedded 
systems that I've seen that depend on the ability to switch VT's for 
their software to work correctly.
>
>>> If we remove the number of devices, those "broken" userspace programs
>>> will also break, so that implies that we should not allow this change.
>> No, the software should just need to be recompiled (I've tested this
>> with ConsoleKit, which also fails gracefully when it tires to open a tty
>> device that doesn't exist), or adapted to dynamically detect the number
>> of TTYs (like it should have in the first place for portability reasons).
>
> We don't do regressions.
Requiring only a recompilation isn't a regression, especially when it 
works fine without being recompiled, and I have yet to actually see 
anything that changing the number of VT's would break other than 
ConsoleKit (systemd-logind might also need a rebuild, but I'm not sure 
about that, and don't have a system I could test it on).
>
>> device drivers). I doubt that it will work out to any more than 16k size
>> difference, but that's still a few more pages (on most systems) that
>> could be used for other things.
>
> And those embedded devices can almost certainly save more by just not
> including the vt layer.
And a few pages can make a difference on _any_ device, not just an 
embedded system.  For a purpose specific system, that can be the 
difference between fitting the working set in memory and having to hit 
swap space.

Re: [PATCH] Add possibility to set /dev/tty number

[Greg KH]

On Tue, Jan 05, 2016 at 08:16:52AM -0500, Austin S. Hemmelgarn wrote:
> >And those embedded devices can almost certainly save more by just not
> >including the vt layer.
> And a few pages can make a difference on _any_ device, not just an embedded
> system.  For a purpose specific system, that can be the difference between
> fitting the working set in memory and having to hit swap space.

No one has proven any memory savings yet, so why are you saying this is
noticable?

thanks,

greg k-h

Re: [PATCH] Add possibility to set /dev/tty number

[Austin S. Hemmelgarn]

On 2016-01-05 10:24, Greg KH wrote:
> On Tue, Jan 05, 2016 at 08:16:52AM -0500, Austin S. Hemmelgarn wrote:
>>> And those embedded devices can almost certainly save more by just not
>>> including the vt layer.
>> And a few pages can make a difference on _any_ device, not just an embedded
>> system.  For a purpose specific system, that can be the difference between
>> fitting the working set in memory and having to hit swap space.
>
> No one has proven any memory savings yet, so why are you saying this is
> noticable?
I didn't mean to imply that the VT subsystem itself was necessarily 
responsible for any space savings, I simply intended to point out that 
savings of a few pages can make a difference.

On that note though, I think I've got something that should work to 
check this across a couple of different configurations, so I'll 
hopefully have results soon.

Re: [PATCH] Add possibility to set /dev/tty number

[Theodore Ts'o]

On Tue, Jan 05, 2016 at 08:16:52AM -0500, Austin S. Hemmelgarn wrote:
> >We don't do regressions.
> Requiring only a recompilation isn't a regression, especially when it works
> fine without being recompiled, and I have yet to actually see anything that
> changing the number of VT's would break other than ConsoleKit
> (systemd-logind might also need a rebuild, but I'm not sure about that, and
> don't have a system I could test it on).

Sorry, breaking a compiled binary is a regression.

People have outlined more clever ways of trying to accomplish your
goal (saving memory) without breaking other people.  I suggest you
give that a try instead of just trying to defend your existing patch.

       		  	   	     - Ted

Re: [PATCH] Add possibility to set /dev/tty number

[Austin S. Hemmelgarn]

On 2016-01-05 11:11, Theodore Ts'o wrote:
> On Tue, Jan 05, 2016 at 08:16:52AM -0500, Austin S. Hemmelgarn wrote:
>>> We don't do regressions.
>> Requiring only a recompilation isn't a regression, especially when it works
>> fine without being recompiled, and I have yet to actually see anything that
>> changing the number of VT's would break other than ConsoleKit
>> (systemd-logind might also need a rebuild, but I'm not sure about that, and
>> don't have a system I could test it on).
>
> Sorry, breaking a compiled binary is a regression.
>
> People have outlined more clever ways of trying to accomplish your
> goal (saving memory) without breaking other people.  I suggest you
> give that a try instead of just trying to defend your existing patch.
>
First, it's not my patch.

Second, my usage of the term 'break' was probably not the best choice 
here, as ConsoleKit doesn't stop working.  All that happens is that it 
spits out some warnings about not finding VT's that it thinks should be 
there.  All that recompiling gets you is that it stops it from spitting 
out these warnings, which could just as easily be suppressed by other 
means.  And, while I can't personally test this, I'm pretty certain that 
the same applies to systemd-logind.  They have to gracefully cope with 
not being able to see all the VT's they think they should, because it's 
fully possible for something to hook into early boot and deallocate most 
of them before ConsoleKit or logind run.

Third, as Greg stated in his response to the patch, it should be updated 
so that the default matches current behavior, which would mean that 
nothing would break unless the person building the kernel chose to break it.

Re: [PATCH] Add possibility to set /dev/tty number

[Pierre Paul MINGOT]

2016-01-04 19:41 GMT+01:00 Austin S. Hemmelgarn <ahferroin7@gmail.com>:
> On 2016-01-04 12:11, Greg KH wrote:
>>
>> On Mon, Jan 04, 2016 at 11:57:33AM -0500, Austin S. Hemmelgarn wrote:
>>>
>>> On 2016-01-04 10:43, Greg KH wrote:
>>>>
>>>> On Mon, Jan 04, 2016 at 04:34:56PM +0100, Pierre Paul MINGOT wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> In Linux there is no way to set the number of tty devices or console
>>>>> to create. By default the kernel create 64 /dev/tty devices. what is
>>>>> too much for embedded system with limited resources.
>>>>
>>>>
>>>> Really?  How much memory does a vt device take up?
>>>
>>> On a device with a simple text mode console in 80x25, a minimum of 2000
>>> bytes, not including anything used for character attributes, and anything
>>> else needed for the display and updating of the screen (I think I worked
>>> out
>>> once that it comes out to about 8k).  On my laptop which has a 1920x1080
>>> screen, using the standard 8x16 VGA font with a framebuffer console via
>>> i915, I get a 200x67 terminal size, which means that just the text
>>> without
>>> any attributes works out to a little more than 13k.  That gets doubled
>>> just
>>> by adding color, and probably doubled again for the other display
>>> attributes.  All of this also doesn't factor in the space taken up in
>>> devtmpfs and sysfs by the associated files (it's not much, but it's still
>>> wasted space).
>>
>>
>> If the console isn't initialized by userspace, is any of that space
>> still really being used?  Have you tried that?
>
> I'm pretty certain that most of the space that gets taken up by the
> scrollback buffer and screen isn't directly used unless the console is used,
> but there are still structures that get allocated at driver instantiation
> for each VT, including the device structures and such.
>>
>>
>>> That said, there are factors to consider other than just memory
>>> footprint:
>>> 1. Having 64 tty devices in /dev leads to somewhat cluttered listings (on
>>> most small systems I see, more than two thirds of the contents of /dev
>>> are
>>> tty device nodes).
>>
>>
>> Not having a cluttered /dev isn't the best reasoning here :)
>
> It wasn't intended as an argument on it's own, simply an additional point.
> It does have an impact though if you're dealing with something like a slow
> serial console, and it also looks _really_ odd having a bunch of device
> nodes for virtual devices that aren't used, and on most systems you can't
> get rid of at runtime (I've always been under the impression that having a
> dynamic /dev was primarily to avoid all the clutter you see there on systems
> like BSD (most derivatives of which still use a statically initialized
> /dev)).
>>
>>
>>> 2. Most people don't know how to switch to anything higher than about tty
>>> 15, a majority of people who have a graphical environment use at most 2
>>> VT's, and a lot of embedded systems use a fixed number of VT's that is
>>> known
>>> prior to full production.
>>
>>
>> Agreed, but does this actually take up memory?
>
> My point here was more that high numbered VT's are something that's pretty
> much unused on most systems, and therefore there is almost zero benefit for
> a majority of people.  At the very least it takes up space for the driver
> internal structures, and the stuff in sysfs.  While a few Kb of memory may
> not seem like much given that servers with close to 1Tb of RAM are starting
> to become common, it can still make a lot of difference in performance for a
> small embedded system.
>>
>>
>>> 3. There is some very poorly designed software out there (at least the
>>> original version of ConsoleKit, and I'd be willing to bet some
>>> third-party
>>> vendor software) which unconditionally starts a thread or process for
>>> each
>>> VT in the system.  While this software should be fixed to behave
>>> properly,
>>> it's infeasible for most end users to do this.
>>
>>
>> If we remove the number of devices, those "broken" userspace programs
>> will also break, so that implies that we should not allow this change.
>
> No, the software should just need to be recompiled (I've tested this with
> ConsoleKit, which also fails gracefully when it tires to open a tty device
> that doesn't exist), or adapted to dynamically detect the number of TTYs
> (like it should have in the first place for portability reasons).
>>
>>
>> Please provide some "real" numbers of memory savings please before
>> saying that this change really does save memory.  Just guessing isn't
>> ok.
>
> I can probably put something together to actually test this, but it will
> take a while (most of my testing scripts and VM's are targeted at regression
> testing of filesystems, not memory profiling of virtual device drivers). I
> doubt that it will work out to any more than 16k size difference, but that's
> still a few more pages (on most systems) that could be used for other
> things.


I totally agree with the points evoked by Austin. Nevertheless, the
interests of this patch are not  ONLY memory consumption or
performance related.
In industrial sector, for obvious security and safety reasons we want
configure our system and have a full control of the devices within it.
So unused or dummy devices are not wanted , not nice to have.
 One way to achieve this goal is to have a full picture of the devices
in our system and then identified which type of applications can run
and then safety or security potential risks. Base on this analysis we
can put in place mandatory actions to fix the risks.
An other interest for reduce dummy /dev devices is hot-plug device
creation detection through inotify or udev. Indeed, we can configure
udev or inotify for monitoring the /dev directory and notify watched
dedicated events. lesser the devices in /dev is better the response
is. This aspect is crucial for RTOS with very high time constraint
near of microseconds. It's the case for example for a system with
Linux RT Patch or Xenomai.

Re: [PATCH] Add possibility to set /dev/tty number

[Austin S. Hemmelgarn]

On 2016-01-05 03:51, Pierre Paul MINGOT wrote:
> 2016-01-04 19:41 GMT+01:00 Austin S. Hemmelgarn <ahferroin7@gmail.com>:
>> On 2016-01-04 12:11, Greg KH wrote:
>>>
>>> On Mon, Jan 04, 2016 at 11:57:33AM -0500, Austin S. Hemmelgarn wrote:
>>>>
>>>> On 2016-01-04 10:43, Greg KH wrote:
>>>>>
>>>>> On Mon, Jan 04, 2016 at 04:34:56PM +0100, Pierre Paul MINGOT wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> In Linux there is no way to set the number of tty devices or console
>>>>>> to create. By default the kernel create 64 /dev/tty devices. what is
>>>>>> too much for embedded system with limited resources.
>>>>>
>>>>>
>>>>> Really?  How much memory does a vt device take up?
>>>>
>>>> On a device with a simple text mode console in 80x25, a minimum of 2000
>>>> bytes, not including anything used for character attributes, and anything
>>>> else needed for the display and updating of the screen (I think I worked
>>>> out
>>>> once that it comes out to about 8k).  On my laptop which has a 1920x1080
>>>> screen, using the standard 8x16 VGA font with a framebuffer console via
>>>> i915, I get a 200x67 terminal size, which means that just the text
>>>> without
>>>> any attributes works out to a little more than 13k.  That gets doubled
>>>> just
>>>> by adding color, and probably doubled again for the other display
>>>> attributes.  All of this also doesn't factor in the space taken up in
>>>> devtmpfs and sysfs by the associated files (it's not much, but it's still
>>>> wasted space).
>>>
>>>
>>> If the console isn't initialized by userspace, is any of that space
>>> still really being used?  Have you tried that?
>>
>> I'm pretty certain that most of the space that gets taken up by the
>> scrollback buffer and screen isn't directly used unless the console is used,
>> but there are still structures that get allocated at driver instantiation
>> for each VT, including the device structures and such.
>>>
>>>
>>>> That said, there are factors to consider other than just memory
>>>> footprint:
>>>> 1. Having 64 tty devices in /dev leads to somewhat cluttered listings (on
>>>> most small systems I see, more than two thirds of the contents of /dev
>>>> are
>>>> tty device nodes).
>>>
>>>
>>> Not having a cluttered /dev isn't the best reasoning here :)
>>
>> It wasn't intended as an argument on it's own, simply an additional point.
>> It does have an impact though if you're dealing with something like a slow
>> serial console, and it also looks _really_ odd having a bunch of device
>> nodes for virtual devices that aren't used, and on most systems you can't
>> get rid of at runtime (I've always been under the impression that having a
>> dynamic /dev was primarily to avoid all the clutter you see there on systems
>> like BSD (most derivatives of which still use a statically initialized
>> /dev)).
>>>
>>>
>>>> 2. Most people don't know how to switch to anything higher than about tty
>>>> 15, a majority of people who have a graphical environment use at most 2
>>>> VT's, and a lot of embedded systems use a fixed number of VT's that is
>>>> known
>>>> prior to full production.
>>>
>>>
>>> Agreed, but does this actually take up memory?
>>
>> My point here was more that high numbered VT's are something that's pretty
>> much unused on most systems, and therefore there is almost zero benefit for
>> a majority of people.  At the very least it takes up space for the driver
>> internal structures, and the stuff in sysfs.  While a few Kb of memory may
>> not seem like much given that servers with close to 1Tb of RAM are starting
>> to become common, it can still make a lot of difference in performance for a
>> small embedded system.
>>>
>>>
>>>> 3. There is some very poorly designed software out there (at least the
>>>> original version of ConsoleKit, and I'd be willing to bet some
>>>> third-party
>>>> vendor software) which unconditionally starts a thread or process for
>>>> each
>>>> VT in the system.  While this software should be fixed to behave
>>>> properly,
>>>> it's infeasible for most end users to do this.
>>>
>>>
>>> If we remove the number of devices, those "broken" userspace programs
>>> will also break, so that implies that we should not allow this change.
>>
>> No, the software should just need to be recompiled (I've tested this with
>> ConsoleKit, which also fails gracefully when it tires to open a tty device
>> that doesn't exist), or adapted to dynamically detect the number of TTYs
>> (like it should have in the first place for portability reasons).
>>>
>>>
>>> Please provide some "real" numbers of memory savings please before
>>> saying that this change really does save memory.  Just guessing isn't
>>> ok.
>>
>> I can probably put something together to actually test this, but it will
>> take a while (most of my testing scripts and VM's are targeted at regression
>> testing of filesystems, not memory profiling of virtual device drivers). I
>> doubt that it will work out to any more than 16k size difference, but that's
>> still a few more pages (on most systems) that could be used for other
>> things.
>
>
> I totally agree with the points evoked by Austin. Nevertheless, the
> interests of this patch are not  ONLY memory consumption or
> performance related.
> In industrial sector, for obvious security and safety reasons we want
> configure our system and have a full control of the devices within it.
> So unused or dummy devices are not wanted , not nice to have.
>   One way to achieve this goal is to have a full picture of the devices
> in our system and then identified which type of applications can run
> and then safety or security potential risks. Base on this analysis we
> can put in place mandatory actions to fix the risks.
I actually hadn't thought of the security auditing aspect, although 
there are arguably much better ways to do hardware auditing than listing 
/dev.
> An other interest for reduce dummy /dev devices is hot-plug device
> creation detection through inotify or udev. Indeed, we can configure
> udev or inotify for monitoring the /dev directory and notify watched
> dedicated events. lesser the devices in /dev is better the response
> is. This aspect is crucial for RTOS with very high time constraint
> near of microseconds. It's the case for example for a system with
> Linux RT Patch or Xenomai.
Unless you're mucking around with binding and unbinding VT's, hot-plug 
overhead from VT's is only an issue at boot, and there are much better 
ways to reduce the amount of time it takes to boot.  Most of the time it 
takes to boot a significant majority of Linux systems is either in 
hardware initialization done by the firmware before even loading Linux, 
or in the userspace init scripts.  As an example of this, the Thinkpad 
L540 laptop I use at the moment for work takes about 60 seconds to go 
from hitting the power button to having a login prompt.  About 20% of 
that time is spent in either the firmware or GRUB, and roughly 70% of 
that time is spent running init scripts.  Most of the time in init 
scripts is NetworkManager starting up, but even if I cut that out, the 
init scripts still take roughly 55% of the time.  Once, shortly after I 
got the hardware, I decided to try running with a static /dev.  It saved 
me rougly 2 seconds of time, and based on the profiling I did, all of 
that was just because of the backlog of uevents, not the number.

If you're really so timing constrained that you can't handle a couple of 
seconds during boot, you should be using a real RTOS like RTEMS or TRON, 
or at least something a lot more lightweight than Linux.

Re: [PATCH] Add possibility to set /dev/tty number

[Greg KH]

On Tue, Jan 05, 2016 at 09:51:14AM +0100, Pierre Paul MINGOT wrote:
> In industrial sector, for obvious security and safety reasons we want
> configure our system and have a full control of the devices within it.
> So unused or dummy devices are not wanted , not nice to have.
>  One way to achieve this goal is to have a full picture of the devices
> in our system and then identified which type of applications can run
> and then safety or security potential risks. Base on this analysis we
> can put in place mandatory actions to fix the risks.
> An other interest for reduce dummy /dev devices is hot-plug device
> creation detection through inotify or udev. Indeed, we can configure
> udev or inotify for monitoring the /dev directory and notify watched
> dedicated events. lesser the devices in /dev is better the response
> is. This aspect is crucial for RTOS with very high time constraint
> near of microseconds. It's the case for example for a system with
> Linux RT Patch or Xenomai.

I don't understand how reducing the number of vt devices makes anything
more or less secure, or better yet, more responsive.  Please provide
specific details showing how this happens.

thanks,

greg k-h

Re: [PATCH] Add possibility to set /dev/tty number

[Austin S. Hemmelgarn]

On 2016-01-05 10:25, Greg KH wrote:
> On Tue, Jan 05, 2016 at 09:51:14AM +0100, Pierre Paul MINGOT wrote:
>> In industrial sector, for obvious security and safety reasons we want
>> configure our system and have a full control of the devices within it.
>> So unused or dummy devices are not wanted , not nice to have.
>>   One way to achieve this goal is to have a full picture of the devices
>> in our system and then identified which type of applications can run
>> and then safety or security potential risks. Base on this analysis we
>> can put in place mandatory actions to fix the risks.
>> An other interest for reduce dummy /dev devices is hot-plug device
>> creation detection through inotify or udev. Indeed, we can configure
>> udev or inotify for monitoring the /dev directory and notify watched
>> dedicated events. lesser the devices in /dev is better the response
>> is. This aspect is crucial for RTOS with very high time constraint
>> near of microseconds. It's the case for example for a system with
>> Linux RT Patch or Xenomai.
>
> I don't understand how reducing the number of vt devices makes anything
> more or less secure, or better yet, more responsive.  Please provide
> specific details showing how this happens.
WRT security, the argument isn't that it makes the system inherently 
more secure, but that it makes it easier to prove the system is secure 
because there are fewer unused device nodes in /dev that you need to 
explain.  In a way, it's a different aspect of the argument that 
reducing the number of VT's makes /dev less cluttered.  I don't 
personally agree with doing hardware auditing via /dev, but that's a 
separate discussion.

As far as the argument about hot-plug overhead, that is an issue (albeit 
a very small one) because that's at least 30+ extra uevents for devices 
that will likely never be used, but it's only an issue during boot 
unless you're doing crazy stuff with allocating and freeing VT's all the 
time.  My statement in my reply to this particular message still applies 
though, if you're _that_ timing constrained, you should be using a real 
RTOS (Linux can do RT, but it's not optimal for it, especially with any 
of the regularly used userspace implementations).

Re: [PATCH] Add possibility to set /dev/tty number

[Greg KH]

On Tue, Jan 05, 2016 at 10:43:45AM -0500, Austin S. Hemmelgarn wrote:
> >I don't understand how reducing the number of vt devices makes anything
> >more or less secure, or better yet, more responsive.  Please provide
> >specific details showing how this happens.
> WRT security, the argument isn't that it makes the system inherently more
> secure, but that it makes it easier to prove the system is secure because
> there are fewer unused device nodes in /dev that you need to explain.

No, the "proof" is the same no matter how many vt device nodes you have.

> In a
> way, it's a different aspect of the argument that reducing the number of
> VT's makes /dev less cluttered.  I don't personally agree with doing
> hardware auditing via /dev, but that's a separate discussion.

It's not a discussion, it's a fallacy.

> As far as the argument about hot-plug overhead, that is an issue (albeit a
> very small one) because that's at least 30+ extra uevents for devices that
> will likely never be used, but it's only an issue during boot unless you're
> doing crazy stuff with allocating and freeing VT's all the time.

How long do those 30+ extra uevents at boot time take?  Can you really
measure that?  Especially given that they aren't even being sent to
userspace because you don't have a running userspace at that point in
time?

> My statement in my reply to this particular message still applies
> though, if you're _that_ timing constrained, you should be using a
> real RTOS (Linux can do RT, but it's not optimal for it, especially
> with any of the regularly used userspace implementations).

RT slows down your machine, so you are not making any sense at all here.

Anyway, why are we even arguing?  There's not a usable patch even
present here to discuss....

greg k-h

Re: [PATCH] Add possibility to set /dev/tty number

[Austin S. Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 2112 bytes --]

On 2016-01-04 13:41, Austin S. Hemmelgarn wrote:
> On 2016-01-04 12:11, Greg KH wrote:
>> Please provide some "real" numbers of memory savings please before
>> saying that this change really does save memory.  Just guessing isn't
>> ok.
> I can probably put something together to actually test this, but it will
> take a while (most of my testing scripts and VM's are targeted at
> regression testing of filesystems, not memory profiling of virtual
> device drivers). I doubt that it will work out to any more than 16k size
> difference, but that's still a few more pages (on most systems) that
> could be used for other things.

As promised, I've got numbers regarding the memory impact.

The system used for testing was a para-virtualized Xen domain running a 
Linux kernel built from these sources:
git://github.com/Ferroin/linux.git
using the attached base config.

The domain used for testing was given 4096 MB or RAM, 4 VCPUS, a PV NIC, 
2 PV disks, and had migration restrictions disabled (nomigrate=1 in the 
domain configuration file).

I tested stock sources with the VT subsystem enabled, stock sources with 
the VT subsystem disabled, and locally modified sources with 
MAX_NR_CONSOLES and MAX_USER_NR_CONSOLES manually changed to 31.

The testing involved booting each configuration 8 times, and comparing 
the MemTotal line form /proc/meminfo.  None of the tests included any 
userspace initialization of the VT's.

Results were 100% stable across each reboot for a given configuration.

Having the full VT subsystem built in, MemTotal showed 4097176 Kb of RAM.
The manually modified version with half the number of VT's showed 
4097228 Kb or RAM.
With the entire VT subsystem compiled out, MemTotal was 4097304 Kb.

This means that not including the VT subsystem resulted in a 128k 
reduction in runtime footprint, and having only half the number of VT's 
resulted in a 52k reduction.  Assuming a linear correlation between the 
number of VT's and the runtime footprint of the subsystem, that means 
the subsystem itself incurs 26k of overhead, and each VT incurs 
approximately 1.6k of overhead.

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 12169 bytes --]

Re: [PATCH] Add possibility to set /dev/tty number

[One Thousand Gnomes]

> This means that not including the VT subsystem resulted in a 128k 
> reduction in runtime footprint, and having only half the number of VT's 
> resulted in a 52k reduction.  Assuming a linear correlation between the 
> number of VT's and the runtime footprint of the subsystem, that means 
> the subsystem itself incurs 26k of overhead, and each VT incurs 
> approximately 1.6k of overhead.

Doesn't seem an unreasonable value - so yes you've made an argument for
dynamically allocating the vt structures when they are first referenced.

Alan

Re: [PATCH] Add possibility to set /dev/tty number

[Austin S. Hemmelgarn]

On 2016-01-05 15:47, One Thousand Gnomes wrote:
>> This means that not including the VT subsystem resulted in a 128k
>> reduction in runtime footprint, and having only half the number of VT's
>> resulted in a 52k reduction.  Assuming a linear correlation between the
>> number of VT's and the runtime footprint of the subsystem, that means
>> the subsystem itself incurs 26k of overhead, and each VT incurs
>> approximately 1.6k of overhead.
>
> Doesn't seem an unreasonable value - so yes you've made an argument for
> dynamically allocating the vt structures when they are first referenced.
No, I've made an argument for finding some way to reduce the runtime 
impact of the VT subsystem.  Dynamic allocation is one way to do that, 
but not the only way.

In fact, there already appears to be some degree of allocation on demand 
for VT's (otherwise deallocvt has no point), just not for everything 
associated with the VT.  I'd be willing to bet that almost everything 
that reasonably can be dynamically allocated already is, there is a bare 
minimum required for even a virtual device after all.

Re: [PATCH] Add possibility to set /dev/tty number

[One Thousand Gnomes]

> In fact, there already appears to be some degree of allocation on demand 
> for VT's (otherwise deallocvt has no point), just not for everything 
> associated with the VT.  I'd be willing to bet that almost everything 
> that reasonably can be dynamically allocated already is, there is a bare 
> minimum required for even a virtual device after all.

If there is 1.6K overhead per vt coming from somewhere (given we only
preallocate 1 VT) then either

- There is stuff not being dynamically allocated (which you can find and
  fix)

- Your userspace is triggering those dynamic allocations

There is no magic thing that requires 1.6K of kernel data per console.

Alan

Re: [PATCH] Add possibility to set /dev/tty number

[Austin S. Hemmelgarn]

On 2016-01-06 08:54, One Thousand Gnomes wrote:
>> In fact, there already appears to be some degree of allocation on demand
>> for VT's (otherwise deallocvt has no point), just not for everything
>> associated with the VT.  I'd be willing to bet that almost everything
>> that reasonably can be dynamically allocated already is, there is a bare
>> minimum required for even a virtual device after all.
>
> If there is 1.6K overhead per vt coming from somewhere (given we only
> preallocate 1 VT) then either
>
> - There is stuff not being dynamically allocated (which you can find and
>    fix)
>
> - Your userspace is triggering those dynamic allocations
>
> There is no magic thing that requires 1.6K of kernel data per console.
There is a bare minimum structure required for something to be 
associated with a device node. The device nodes exist regardless, and 
the dynamic allocation of the other things (like the screen state, the 
output buffer, etc) gets triggered on first access to the node. 1.6k is 
probably not the absolute minimum it could be, but there are still 
things that need to be there for it to behave the way it's supposed to. 
  At a minimum, you need stuff to associate the device numbers, handle 
the tty ioctls, handle device node access, and probably an associated 
lock or two to maintain consistency.  None of that can reasonably be 
dynamically allocated without multiplexing everything through a single 
underlying virtual device (kind of like is done with PTY's) or adding 
some new system calls to manage it, except that that would change the 
userspace API, and thus be a regression.

Re: [PATCH] Add possibility to set /dev/tty number

[Austin S. Hemmelgarn]

On 2016-01-04 10:34, Pierre Paul MINGOT wrote:
> Hello,
> 
> In Linux there is no way to set the number of tty devices or console
> to create. By default the kernel create 64 /dev/tty devices. what is
> too much for embedded system with limited resources. As all these 64
> devices are not necessary or mandatory for the kernel proper working,
> I add a config option to set the desired tty. The lowest number you
> can set is 1 and the highest is 63, any value respectively below or
> above that, will cause a kconfig invalid entry pop-up.
> 
> Please keep me update.
> 
> Best Regards
> 
OK, circling back since I never commented on the original patch.  Greg covered most of the basics regarding formatting, so I won't comment on that.
 
>+config NR_TTY_DEVICES
>+    int "Maximum tty device number"
>+    depends on VT
>+    range 1 63
>+    default 1

The config item should default to the current value of 63, as it changes the userspace visible ABI otherwise.  It should also probably depend on EXPERT, as this isn't something that should be arbitrarily changed by most people building the kernel.

> #define MIN_NR_CONSOLES 1       /* must be at least 1 */
>-#define MAX_NR_CONSOLES	63	/* serial lines start at 64 */
>-#define MAX_NR_USER_CONSOLES 63	/* must be root to allocate above this */
>+/* serial lines start at 64 */
>+#define MAX_NR_CONSOLES	 CONFIG_NR_TTY_DEVICES
>+/* must be root to allocate above this */
>+#define MAX_NR_USER_CONSOLES CONFIG_NR_TTY_DEVICES

This shouldn't affect serial console numbering, as the minimum serial console minor number isn't defined relative to either of the values here.

Using #define to define things relative to Kconfig values in uapi headers doesn't work (at least, not just doing it with a simple #define, there might be some way to do it, but I have yet to see it), these would need to get parsed when the headers get installed, so this patch would result in MAX_NR_CONSOLES and MAX_NR_USER_CONSOLES being undefined in the userspace headers because userspace doesn't have direct access to any of the CONFIG values.