linux-kernel - Re: [PATCH v2] vt: add init_hide parameter to suppress boot output

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, 19 Feb 2013 20:45:06 -0800
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Andy Ross <andy.ross@...driver.com>
Cc:	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Jiri Slaby <jslaby@...e.cz>, Pavel Machek <pavel@....cz>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Len Brown <len.brown@...el.com>,
	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH v2] vt: add init_hide parameter to suppress boot output

On Tue, Feb 19, 2013 at 08:04:05PM -0800, Andy Ross wrote:
> On 02/19/2013 05:45 PM, Greg Kroah-Hartman wrote:
> >>When vt.init_hide is set, suppress output on newly created consoles
> >>until an affirmative switched to that console.  This prevents boot
> >>output from displaying (and clobbering splash screens, etc...)
> >>without disabling the console entirely.
> >
> >What's wrong with the 'quiet' option we have?  And you forgot to
> >document this.
> 
> You're right about docs, obviously.  I'll write something up and send
> it tomorrow morning.
> 
> But setting "quiet" controls logging.  It won't prevent the console
> from doing a buffer clear or mode switch, nor will it prevent
> userspace from writing to it, nor will the buffer rewrites due to the
> console switches that happen on suspend and resume (which I didn't
> know existed) be suppressed.
> 
> There's a (sort of) similar commonly-used option, vga=current, which
> prevents a mode switch for the special case of VGA/vesa.  But that
> doesn't work with the framebuffer console.

Why not?  Can't you fix that?

> The idea here (and I'm clearly no domain expert) was to leave the
> console enabled and active, but invisible by default.  So nothing
> displays, the splash screen stays put, and nothing fights with other
> users of the framebuffer.  And it stays that way until something
> affirmatively switches to a different VT using chvt or Alt-Fn or
> whatever.
> 
> To be fair, a lot of this could be managed in userspace with the VT_*
> ioctl interface.

Yes, that's what "normal" systems do :)

> But the specific application here (Android's surfaceflinger) isn't set
> up for that, and it's a non-trivial API (and even doing it "right"
> involves racing against other users at startup).

How could there be any other users at startup, you "own" the system
here, there should not be anyone to race with.

> This seemed like a much simpler metaphor that still meets the
> requirements.

I think you should use the ioctls, that is what they are there for, and
is what you need to implement if you want to use a console anyway,
right?

greg k-h
--
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/