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

From: Max Staudt <mstaudt@suse.de>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "Linux Fbdev development list" <linux-fbdev@vger.kernel.org>,
	michal@markovi.net,
	"Bartlomiej Zolnierkiewicz" <b.zolnierkie@samsung.com>,
	sndirsch@suse.com, "Oliver Neukum" <oneukum@suse.com>,
	"Takashi Iwai" <tiwai@suse.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Neil Armstrong" <narmstrong@baylibre.com>,
	philm@manjaro.org,
	"Bero Rosenkränzer" <bernhard.rosenkranzer@linaro.org>
Subject: Re: [RFC PATCH v2 00/13] Kernel based bootsplash
Date: Wed, 20 Dec 2017 17:15:45 +0100	[thread overview]
Message-ID: <bb02d299-0ff7-0fc6-0828-9724889f9d44@suse.de> (raw)
In-Reply-To: <CAKMK7uE+4LrX0U6JWgQuFD3RLVOoNOi8oTAs8N3QjwqULv-fCQ@mail.gmail.com>

On 12/20/2017 04:11 PM, Daniel Vetter wrote:
> So fundamentally I don't think an in-kernel bootsplash is a bad idea.
> But most likely you want this on a highly embedded system, which
> probably is compiled for your exact hw, with pretty much everything
> built in. Also, no fbcon, maybe even no vt subsystem at all.
> Definitely not your general purpose distro.

If an embedded distro can use it, then so can a general purpose distro that doesn't want to use Plymouth.

It's useful in many cases.

> Your proposal to work on top of fbcon doesn't fix that niche.

It does fix it very well - it's just that it also requires fbcon.
And I'm glad to fix this if you have a good idea for a cleaner alternative.

> Now for your problem, which seems to be to have a working bootsplash
> for a general purpose distro, specifically for the bug where plymouth
> prevents the real drm driver from loading: Adding an in-kernel
> bootsplash doesn't make any sense, at least not to me. Instead I think
> the right action is to fix the problem, both in the kernel and in
> userspace.

So we SIGBUS any process using the framebuffer just because we're loading an alternative driver, which uses a hack to kick out the old driver?

It's loading the new driver that should fail because the hardware resource is busy serving the old driver!
Not existing applications being killed. This is horribly broken semantics.

Just like unloading a driver that's still in use MUST fail. Not kill the processes using it!

And if it fails to load with -EBUSY, as it should, then the bug still stands.

> All the problems below have fairly simple solutions, but there's imo
> no point in talking technical solutions for specific problems when
> we're trying to fix the wrong problem.

The problem is that a splash in userspace brings horrible hacks and workarounds into the room. We're already discussing killing processes!

No, just no. Processes aren't ours to kill willy-nilly.

Max
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel