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] [day] [month] [year] [list]
Message-ID: <CANq1E4TFkTjy2rSuHxeAkw87y2nrhQAQDOfiYi7ZtunnMKDKoA@mail.gmail.com>
Date:	Fri, 13 Sep 2013 12:58:36 +0200
From:	David Herrmann <dh.herrmann@...il.com>
To:	Adam Borowski <kilobyte@...band.pl>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] vt: properly ignore xterm-256 colour codes

Hi

On Thu, Sep 12, 2013 at 3:24 PM, Adam Borowski <kilobyte@...band.pl> wrote:
> On Thu, Sep 12, 2013 at 02:37:26PM +0200, David Herrmann wrote:
>> On Mon, Sep 9, 2013 at 6:46 PM, Adam Borowski <kilobyte@...band.pl> wrote:
>> > On Mon, Sep 09, 2013 at 05:53:19PM +0200, David Herrmann wrote:
>> > [...]
>> >> Btw., you should put Greg Kroah-Hartman and Andrew Morton on CC. Both
>> >> are the most likely to pick this up.
>> >
>> > Thanks for the suggestion.  I've sent the patch two days ago to Jiri Slaby
>> > (listed as a maintainer besides Greg) together with a newbie question, but
>> > he's apparently busy.
>>
>> Jiri Slaby maintains the TTY subsystem (together with Greg). This does
>> not include the VT layer, though. drivers/tty/vt/ and
>> drivers/video/console/ are unmaintained. You need to get the attention
>> of any maintainer who is willing to take it through their tree (hint:
>> most maintainers don't dare touching the VT layer. Greg and Andrew
>> were brave enough in the past.).
>>
>> I'm willing to review your patches
>
> Thanks.  So I shouldn't bother anyone else for now to get My First Kernel
> Patch(tm) into 3.12 (or, if it's too late, into something included in 3.13),
> right?

Too late for 3.12. We want such stuff in linux-next before it is
merged. So yeah, 3.13 should be your aim.

>> > I've got more changes for the vt, but there's no hurry, I wanted to test
>> > the waters with a single minor one in 3.12 first.
>
>> drivers/tty/vt/ and drivers/video/console/ are unmaintained.
>
>> [...] but history taught me touching the VT layer is a waste of time.
>
> Could you tell me why?

Because few people care (did anyone but me respond to this?).
Furthermore, most people just want it to "not break", they often don't
care for improvements.

> The console is an important tool when something
> fails.

That's true for any recovery tool.

> Of course, fancy schmancy stuff like combining characters, etc,
> could be better done in that legendary userspace alternate console layer,
> but the built-in VT must remain at least functional. And getting corrupted
> text is not nice; the VT has fallen woefully behind what works on any other
> modern terminal.
>
> Back by ~2000, I'd say it worked better than rxvt, xterm, or, Cthulhu help
> us, Solaris' terminal.  It just needs some maintenance.

Yes, the linux-console used to be something people were proud of. But
there ought to be a reason why it has fallen behind. You might wanna
figure that out before spending time fixing the symptom.

> I had a bunch of other improvements planned; if you say that's a waste of
> time perhaps I should scale that back.  But I'd still want to at least
> make sure programs that don't use terminfo (terminfo is a bad joke) won't
> spew ANSI codes to the screen; at least more popular ones like "set window
> title", etc.
>
> You might know of other clean-up and fixes that need to be done here,
> though.

I'm not saying that I dislike the effort. Please go ahead. But you
might want to have a look at "git log drivers/tty/vt/vt.c". There
hasn't been any serious VT changes since 2010. Neither for
drivers/char/vt.c which it was back then. I think this effort is
better spent on user-space consoles, but I might be biased.

Regards
David
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ