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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

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