Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754403AbdLTQPw (ORCPT ); Wed, 20 Dec 2017 11:15:52 -0500 Received: from mx2.suse.de ([195.135.220.15]:39154 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751960AbdLTQPs (ORCPT ); Wed, 20 Dec 2017 11:15:48 -0500 Subject: Re: [RFC PATCH v2 00/13] Kernel based bootsplash To: Daniel Vetter Cc: Neil Armstrong , Bartlomiej Zolnierkiewicz , Linux Fbdev development list , michal@markovi.net, sndirsch@suse.com, Oliver Neukum , Takashi Iwai , dri-devel , Linux Kernel Mailing List , =?UTF-8?Q?Bero_Rosenkr=c3=a4nzer?= , philm@manjaro.org References: <20171213194755.3409-1-mstaudt@suse.de> <20171219161630.GI26573@phenom.ffwll.local> <2f8a1a08-911d-a511-2968-4d89418ac212@suse.de> <573d4050-7607-b8e4-7552-83966f551ba3@suse.de> <20171220094355.GJ26573@phenom.ffwll.local> <20171220101421.GM26573@phenom.ffwll.local> <5dc7f218-9113-fad3-c0a8-883c4bae4e02@suse.de> From: Max Staudt Message-ID: Date: Wed, 20 Dec 2017 17:15:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1958 Lines: 46 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