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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 5 Jan 2016 08:16:52 -0500
From:	"Austin S. Hemmelgarn" <ahferroin7@...il.com>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Pierre Paul MINGOT <mingot.pierre@...il.com>, jslaby@...e.cz,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Add possibility to set /dev/tty number

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/