linux-kernel - Re: [RFC PATCH v2 00/13] Kernel based bootsplash

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 for Android: free password hash cracker in your pocket

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

Message-ID: <ebdbab02-a2ab-6250-ee0f-717635f807cd@suse.de>
Date:   Wed, 3 Jan 2018 18:56:31 +0100
From:   Max Staudt <mstaudt@...e.de>
To:     Alan Cox <gnomes@...rguk.ukuu.org.uk>
Cc:     Daniel Vetter <daniel@...ll.ch>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
        michal@...kovi.net, sndirsch@...e.com,
        Oliver Neukum <oneukum@...e.com>,
        Takashi Iwai <tiwai@...e.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Bero Rosenkränzer 
        <bernhard.rosenkranzer@...aro.org>, philm@...jaro.org
Subject: Re: [RFC PATCH v2 00/13] Kernel based bootsplash

On 12/31/2017 01:35 PM, Alan Cox wrote:
> For embedded every KB counts. That is likely to remain the same for some
> time because at the end of the day small devices are constrained about the
> amount of SRAM you can put on die and the amount of power you can afford
> for DRAM. 

Fascinating, thanks for the insight!

Now I have a really good reason to separate the splash from fbcon.


>>> this by ignoring it an adding a hole new layer on top. That doesn't
>>> sound like any kind of good idea to me.  
>>
>> Yes. It is a vast improvement over the status quo, and people are asking for it. And the bootsplash layer can be moved elsewhere, just change the hooks and keep the loading/rendering.
>>
>> Also, gfx driver loading isn't a dumpster fire, it mostly just works. It just mustn't be done 100% carelessly.
> 
> It's a total mess (the fbcon layer loading and locking that is). Doing all
> this extra kernel stuff is like sitting in a hole and instead of trying to
> climb out digging the hole bigger so you've got more room to sit in it.
I'm not sure what exactly you're unhappy about - are you complaining about the kernel hack in KMS drivers which allows them to kick out vesafb/efifb?



Max