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

[Pierre Paul MINGOT]

2016-01-04 19:41 GMT+01:00 Austin S. Hemmelgarn <ahferroin7@xxxxxxxxx>:
> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/