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]

Message-ID: <20130220181258.GC6679@kroah.com>
Date:	Wed, 20 Feb 2013 10:12:58 -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 Wed, Feb 20, 2013 at 08:54:47AM -0800, Andy Ross wrote:
> On 02/19/2013 08:45 PM, Greg Kroah-Hartman wrote:
> > On Tue, Feb 19, 2013 at 08:04:05PM -0800, Andy Ross wrote:
> > > 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?
> 
> I'd argue that's what this is.  If you were going to design a "shut up
> the console" feature from scratch, would you choose to do it in one
> particular display driver or would you do it in the device-independent
> console code by forcing the already-existing "visible" flag to false?

I don't know.  All I do know is that by adding yet-another-userspace
option, we will have to support it for 20+ years.  And I'm _really_
hesitant to do so, especially for a subsystem that, if all goes well, we
will be able to just entirely disable soon.

> > > 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.
> 
> Tell that to the display hardware. :)

On Android you own that as well, so there this isn't an excuse :)

> Seriously, every Linux box with a display (to first approximation,
> obviously I didn't test them all while writing this message) spits
> something to the screen between the moment where the bootloader hands
> off control and the display driver is initialized.  Most of them
> glitch a little at suspend time because of the console switch there.
> I just reproduced both of these effects with a Fedora 18 live image.

That's Fedora's issue, not Android's.

And it's really a DRM issue, and as mentioned above, one that people are
already working on resolving by just getting rid of this whole layer
entirely.  So adding new options to it are something that I really don't
want to do, especially as we already have working prototypes that don't
have this problem.

> This fixes almost all of that (vga=current is still required because
> some early logging somewhere seems to write to the screen by banging
> registers directly and not using the console), and it does it in a way
> that works without having to modify existing userspace or (try to)
> remove the framebuffer console entirely.

Then fix that early logging code, don't paper over it by doing something
like this please.  Or just remove the framebuffer entirely, it's not
needed, no one will miss it...

thanks,

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/