From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754728AbdLTJoH (ORCPT ); Wed, 20 Dec 2017 04:44:07 -0500 Received: from mail-wm0-f65.google.com ([74.125.82.65]:43602 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754641AbdLTJn7 (ORCPT ); Wed, 20 Dec 2017 04:43:59 -0500 X-Google-Smtp-Source: ACJfBouJ659g4N1N04F8+lcY+why09VFhCexImTE/rpjSfacB1nx821ugeRYJbO2rTgl7u+j8U99MQ== Date: Wed, 20 Dec 2017 10:43:55 +0100 From: Daniel Vetter To: Max Staudt Cc: Daniel Vetter , Bartlomiej Zolnierkiewicz , Linux Fbdev development list , michal@markovi.net, sndirsch@suse.com, Oliver Neukum , Takashi Iwai , dri-devel , Linux Kernel Mailing List , Bero =?iso-8859-1?Q?Rosenkr=E4nzer?= , philm@manjaro.org Subject: Re: [RFC PATCH v2 00/13] Kernel based bootsplash Message-ID: <20171220094355.GJ26573@phenom.ffwll.local> Mail-Followup-To: Max Staudt , Bartlomiej Zolnierkiewicz , Linux Fbdev development list , michal@markovi.net, sndirsch@suse.com, Oliver Neukum , Takashi Iwai , dri-devel , Linux Kernel Mailing List , Bero =?iso-8859-1?Q?Rosenkr=E4nzer?= , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <573d4050-7607-b8e4-7552-83966f551ba3@suse.de> X-Operating-System: Linux phenom 4.13.0-1-amd64 User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote: > On 12/19/2017 06:26 PM, Daniel Vetter wrote: > > On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt wrote: > >> Well, those could enable fbcon if they want the bootsplash. Shouldn't make a difference anyway if they're powerful enough to run Linux. As long as the bootsplash is shown, no fbcon drawing operations are executed, so there is no expensive scrolling or such to hog the system. > > > > It's too big, and those folks tend to be super picky about space. > > I know, they really are. > > However, given just how big and clunky modern systems have become, I > raise my doubts about a few extra KB for fbcon code to be relevant. > > My feeling is that the kernel splash probably saves even more space on > the userspace side than it adds on the kernel side, thus netting a > reduction in overall code size. > > > > So essentially you're telling me that on a current general purpose > > distro the gfx driver loading is a dumpster fire, and we're fixing > > 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. You've talked about using sleep and stuff to paper over races. That doesn't sound good at all. > > So if just using drm for everything isn't possible (since drm drivers > > can at least in theory be hotunplugged), can we at least fix the > > existing fbdev kernel bugs? Not being able to unplug a drm driver when > > it's still open sounds like a rather serious issues that probably > > should be fixed anyway ... so we're better able to hotunplug an fbdev > > driver when it's in use. > > I don't see it as a bug. The fbdev driver gets unloaded as much as > possible, but as long as a userspace application keeps the address_space > mmap()ed, there's nothing we can do, short of forcibly removing it and > segfaulting the process the next time it tries to render something. Am I > missing something? I guess you could remap that too ... But yeah SIGBUS ftw. Wrap rendering in a sighandler and abort if you hit that. In drm we try to be a bit better and keep things around until userspace has gone. > > Also I'm not clear at all on the "papering over races with sleeps" > > part. DRM drivers shouldn't be racy when getting loaded ... > > The DRM driver loading isn't racy, but the fbdev can't be fully unloaded > while Plymouth has the address_space mmap()ed. If Plymouth sleeps until > drivers that are included in initramfs are (hopefully) loaded, then it > will forego using its FB backend. > > A solution we've experimented with is dropping the FB backend from > Plymouth. It instantly fixed the busy video RAM bug. However it made the > folks relying on efifb very, very unhappy. > > > > Or we get simpledrm merged (for efifb and vesafb support) and someone > > types the xendrm driver (there is floating around, it's just old) and > > we could forget about any real fbdev drivers except the drm based > > ones. > > And drmcon, unless we come up with a better idea than hooking into the *con driver. If we have everything as drm drivers, you can just use plymouth (with no fbdev backend ofc) and everyone is happy. Including the efifb folks (it's simply going to be called efidrmfb or something like that). So no idea why you need a *con. > Sure, that'd help a lot. But what do we do until then? Make it happen? Twiddling thumbs is an option too ofc, but it tends to not result in results :-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Date: Wed, 20 Dec 2017 09:43:55 +0000 Subject: Re: [RFC PATCH v2 00/13] Kernel based bootsplash Message-Id: <20171220094355.GJ26573@phenom.ffwll.local> List-Id: 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> In-Reply-To: <573d4050-7607-b8e4-7552-83966f551ba3@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Max Staudt Cc: Linux Fbdev development list , michal@markovi.net, Bartlomiej Zolnierkiewicz , sndirsch@suse.com, Oliver Neukum , Takashi Iwai , dri-devel , Linux Kernel Mailing List , philm@manjaro.org, Bero =?iso-8859-1?Q?Rosenkr=E4nzer?= On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote: > On 12/19/2017 06:26 PM, Daniel Vetter wrote: > > On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt wrote: > >> Well, those could enable fbcon if they want the bootsplash. Shouldn't make a difference anyway if they're powerful enough to run Linux. As long as the bootsplash is shown, no fbcon drawing operations are executed, so there is no expensive scrolling or such to hog the system. > > > > It's too big, and those folks tend to be super picky about space. > > I know, they really are. > > However, given just how big and clunky modern systems have become, I > raise my doubts about a few extra KB for fbcon code to be relevant. > > My feeling is that the kernel splash probably saves even more space on > the userspace side than it adds on the kernel side, thus netting a > reduction in overall code size. > > > > So essentially you're telling me that on a current general purpose > > distro the gfx driver loading is a dumpster fire, and we're fixing > > 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. You've talked about using sleep and stuff to paper over races. That doesn't sound good at all. > > So if just using drm for everything isn't possible (since drm drivers > > can at least in theory be hotunplugged), can we at least fix the > > existing fbdev kernel bugs? Not being able to unplug a drm driver when > > it's still open sounds like a rather serious issues that probably > > should be fixed anyway ... so we're better able to hotunplug an fbdev > > driver when it's in use. > > I don't see it as a bug. The fbdev driver gets unloaded as much as > possible, but as long as a userspace application keeps the address_space > mmap()ed, there's nothing we can do, short of forcibly removing it and > segfaulting the process the next time it tries to render something. Am I > missing something? I guess you could remap that too ... But yeah SIGBUS ftw. Wrap rendering in a sighandler and abort if you hit that. In drm we try to be a bit better and keep things around until userspace has gone. > > Also I'm not clear at all on the "papering over races with sleeps" > > part. DRM drivers shouldn't be racy when getting loaded ... > > The DRM driver loading isn't racy, but the fbdev can't be fully unloaded > while Plymouth has the address_space mmap()ed. If Plymouth sleeps until > drivers that are included in initramfs are (hopefully) loaded, then it > will forego using its FB backend. > > A solution we've experimented with is dropping the FB backend from > Plymouth. It instantly fixed the busy video RAM bug. However it made the > folks relying on efifb very, very unhappy. > > > > Or we get simpledrm merged (for efifb and vesafb support) and someone > > types the xendrm driver (there is floating around, it's just old) and > > we could forget about any real fbdev drivers except the drm based > > ones. > > And drmcon, unless we come up with a better idea than hooking into the *con driver. If we have everything as drm drivers, you can just use plymouth (with no fbdev backend ofc) and everyone is happy. Including the efifb folks (it's simply going to be called efidrmfb or something like that). So no idea why you need a *con. > Sure, that'd help a lot. But what do we do until then? Make it happen? Twiddling thumbs is an option too ofc, but it tends to not result in results :-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [RFC PATCH v2 00/13] Kernel based bootsplash Date: Wed, 20 Dec 2017 10:43:55 +0100 Message-ID: <20171220094355.GJ26573@phenom.ffwll.local> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) by gabe.freedesktop.org (Postfix) with ESMTPS id C77536E37E for ; Wed, 20 Dec 2017 09:43:59 +0000 (UTC) Received: by mail-wm0-x243.google.com with SMTP id 9so8573097wme.4 for ; Wed, 20 Dec 2017 01:43:59 -0800 (PST) Content-Disposition: inline In-Reply-To: <573d4050-7607-b8e4-7552-83966f551ba3@suse.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Max Staudt Cc: Linux Fbdev development list , michal@markovi.net, Bartlomiej Zolnierkiewicz , sndirsch@suse.com, Oliver Neukum , Takashi Iwai , dri-devel , Linux Kernel Mailing List , philm@manjaro.org, Bero =?iso-8859-1?Q?Rosenkr=E4nzer?= List-Id: dri-devel@lists.freedesktop.org T24gVHVlLCBEZWMgMTksIDIwMTcgYXQgMDc6NDA6MTJQTSArMDEwMCwgTWF4IFN0YXVkdCB3cm90 ZToKPiBPbiAxMi8xOS8yMDE3IDA2OjI2IFBNLCBEYW5pZWwgVmV0dGVyIHdyb3RlOgo+ID4gT24g VHVlLCBEZWMgMTksIDIwMTcgYXQgNjowNCBQTSwgTWF4IFN0YXVkdCA8bXN0YXVkdEBzdXNlLmRl PiB3cm90ZToKPiA+PiBXZWxsLCB0aG9zZSBjb3VsZCBlbmFibGUgZmJjb24gaWYgdGhleSB3YW50 IHRoZSBib290c3BsYXNoLiBTaG91bGRuJ3QgbWFrZSBhIGRpZmZlcmVuY2UgYW55d2F5IGlmIHRo ZXkncmUgcG93ZXJmdWwgZW5vdWdoIHRvIHJ1biBMaW51eC4gQXMgbG9uZyBhcyB0aGUgYm9vdHNw bGFzaCBpcyBzaG93biwgbm8gZmJjb24gZHJhd2luZyBvcGVyYXRpb25zIGFyZSBleGVjdXRlZCwg c28gdGhlcmUgaXMgbm8gZXhwZW5zaXZlIHNjcm9sbGluZyBvciBzdWNoIHRvIGhvZyB0aGUgc3lz dGVtLgo+ID4gCj4gPiBJdCdzIHRvbyBiaWcsIGFuZCB0aG9zZSBmb2xrcyB0ZW5kIHRvIGJlIHN1 cGVyIHBpY2t5IGFib3V0IHNwYWNlLgo+IAo+IEkga25vdywgdGhleSByZWFsbHkgYXJlLgo+IAo+ IEhvd2V2ZXIsIGdpdmVuIGp1c3QgaG93IGJpZyBhbmQgY2x1bmt5IG1vZGVybiBzeXN0ZW1zIGhh dmUgYmVjb21lLCBJCj4gcmFpc2UgbXkgZG91YnRzIGFib3V0IGEgZmV3IGV4dHJhIEtCIGZvciBm YmNvbiBjb2RlIHRvIGJlIHJlbGV2YW50Lgo+IAo+IE15IGZlZWxpbmcgaXMgdGhhdCB0aGUga2Vy bmVsIHNwbGFzaCBwcm9iYWJseSBzYXZlcyBldmVuIG1vcmUgc3BhY2Ugb24KPiB0aGUgdXNlcnNw YWNlIHNpZGUgdGhhbiBpdCBhZGRzIG9uIHRoZSBrZXJuZWwgc2lkZSwgdGh1cyBuZXR0aW5nIGEK PiByZWR1Y3Rpb24gaW4gb3ZlcmFsbCBjb2RlIHNpemUuCj4gCj4gCj4gPiBTbyBlc3NlbnRpYWxs eSB5b3UncmUgdGVsbGluZyBtZSB0aGF0IG9uIGEgY3VycmVudCBnZW5lcmFsIHB1cnBvc2UKPiA+ IGRpc3RybyB0aGUgZ2Z4IGRyaXZlciBsb2FkaW5nIGlzIGEgZHVtcHN0ZXIgZmlyZSwgYW5kIHdl J3JlIGZpeGluZwo+ID4gdGhpcyBieSBpZ25vcmluZyBpdCBhbiBhZGRpbmcgYSBob2xlIG5ldyBs YXllciBvbiB0b3AuIFRoYXQgZG9lc24ndAo+ID4gc291bmQgbGlrZSBhbnkga2luZCBvZiBnb29k IGlkZWEgdG8gbWUuCj4gCj4gWWVzLiBJdCBpcyBhIHZhc3QgaW1wcm92ZW1lbnQgb3ZlciB0aGUg c3RhdHVzIHF1bywgYW5kIHBlb3BsZSBhcmUgYXNraW5nCj4gZm9yIGl0LiBBbmQgdGhlIGJvb3Rz cGxhc2ggbGF5ZXIgY2FuIGJlIG1vdmVkIGVsc2V3aGVyZSwganVzdCBjaGFuZ2UgdGhlCj4gaG9v a3MgYW5kIGtlZXAgdGhlIGxvYWRpbmcvcmVuZGVyaW5nLgo+IAo+IEFsc28sIGdmeCBkcml2ZXIg bG9hZGluZyBpc24ndCBhIGR1bXBzdGVyIGZpcmUsIGl0IG1vc3RseSBqdXN0IHdvcmtzLiBJdAo+ IGp1c3QgbXVzdG4ndCBiZSBkb25lIDEwMCUgY2FyZWxlc3NseS4KCllvdSd2ZSB0YWxrZWQgYWJv dXQgdXNpbmcgc2xlZXAgYW5kIHN0dWZmIHRvIHBhcGVyIG92ZXIgcmFjZXMuIFRoYXQKZG9lc24n dCBzb3VuZCBnb29kIGF0IGFsbC4KCj4gPiBTbyBpZiBqdXN0IHVzaW5nIGRybSBmb3IgZXZlcnl0 aGluZyBpc24ndCBwb3NzaWJsZSAoc2luY2UgZHJtIGRyaXZlcnMKPiA+IGNhbiBhdCBsZWFzdCBp biB0aGVvcnkgYmUgaG90dW5wbHVnZ2VkKSwgY2FuIHdlIGF0IGxlYXN0IGZpeCB0aGUKPiA+IGV4 aXN0aW5nIGZiZGV2IGtlcm5lbCBidWdzPyBOb3QgYmVpbmcgYWJsZSB0byB1bnBsdWcgYSBkcm0g ZHJpdmVyIHdoZW4KPiA+IGl0J3Mgc3RpbGwgb3BlbiBzb3VuZHMgbGlrZSBhIHJhdGhlciBzZXJp b3VzIGlzc3VlcyB0aGF0IHByb2JhYmx5Cj4gPiBzaG91bGQgYmUgZml4ZWQgYW55d2F5IC4uLiBz byB3ZSdyZSBiZXR0ZXIgYWJsZSB0byBob3R1bnBsdWcgYW4gZmJkZXYKPiA+IGRyaXZlciB3aGVu IGl0J3MgaW4gdXNlLgo+IAo+IEkgZG9uJ3Qgc2VlIGl0IGFzIGEgYnVnLiBUaGUgZmJkZXYgZHJp dmVyIGdldHMgdW5sb2FkZWQgYXMgbXVjaCBhcwo+IHBvc3NpYmxlLCBidXQgYXMgbG9uZyBhcyBh IHVzZXJzcGFjZSBhcHBsaWNhdGlvbiBrZWVwcyB0aGUgYWRkcmVzc19zcGFjZQo+IG1tYXAoKWVk LCB0aGVyZSdzIG5vdGhpbmcgd2UgY2FuIGRvLCBzaG9ydCBvZiBmb3JjaWJseSByZW1vdmluZyBp dCBhbmQKPiBzZWdmYXVsdGluZyB0aGUgcHJvY2VzcyB0aGUgbmV4dCB0aW1lIGl0IHRyaWVzIHRv IHJlbmRlciBzb21ldGhpbmcuIEFtIEkKPiBtaXNzaW5nIHNvbWV0aGluZz8KCkkgZ3Vlc3MgeW91 IGNvdWxkIHJlbWFwIHRoYXQgdG9vIC4uLiBCdXQgeWVhaCBTSUdCVVMgZnR3LiBXcmFwIHJlbmRl cmluZwppbiBhIHNpZ2hhbmRsZXIgYW5kIGFib3J0IGlmIHlvdSBoaXQgdGhhdC4gSW4gZHJtIHdl IHRyeSB0byBiZSBhIGJpdApiZXR0ZXIgYW5kIGtlZXAgdGhpbmdzIGFyb3VuZCB1bnRpbCB1c2Vy c3BhY2UgaGFzIGdvbmUuCgo+ID4gQWxzbyBJJ20gbm90IGNsZWFyIGF0IGFsbCBvbiB0aGUgInBh cGVyaW5nIG92ZXIgcmFjZXMgd2l0aCBzbGVlcHMiCj4gPiBwYXJ0LiBEUk0gZHJpdmVycyBzaG91 bGRuJ3QgYmUgcmFjeSB3aGVuIGdldHRpbmcgbG9hZGVkIC4uLgo+IAo+IFRoZSBEUk0gZHJpdmVy IGxvYWRpbmcgaXNuJ3QgcmFjeSwgYnV0IHRoZSBmYmRldiBjYW4ndCBiZSBmdWxseSB1bmxvYWRl ZAo+IHdoaWxlIFBseW1vdXRoIGhhcyB0aGUgYWRkcmVzc19zcGFjZSBtbWFwKCllZC4gSWYgUGx5 bW91dGggc2xlZXBzIHVudGlsCj4gZHJpdmVycyB0aGF0IGFyZSBpbmNsdWRlZCBpbiBpbml0cmFt ZnMgYXJlIChob3BlZnVsbHkpIGxvYWRlZCwgdGhlbiBpdAo+IHdpbGwgZm9yZWdvIHVzaW5nIGl0 cyBGQiBiYWNrZW5kLgo+IAo+IEEgc29sdXRpb24gd2UndmUgZXhwZXJpbWVudGVkIHdpdGggaXMg ZHJvcHBpbmcgdGhlIEZCIGJhY2tlbmQgZnJvbQo+IFBseW1vdXRoLiBJdCBpbnN0YW50bHkgZml4 ZWQgdGhlIGJ1c3kgdmlkZW8gUkFNIGJ1Zy4gSG93ZXZlciBpdCBtYWRlIHRoZQo+IGZvbGtzIHJl bHlpbmcgb24gZWZpZmIgdmVyeSwgdmVyeSB1bmhhcHB5Lgo+IAo+IAo+ID4gT3Igd2UgZ2V0IHNp bXBsZWRybSBtZXJnZWQgKGZvciBlZmlmYiBhbmQgdmVzYWZiIHN1cHBvcnQpIGFuZCBzb21lb25l Cj4gPiB0eXBlcyB0aGUgeGVuZHJtIGRyaXZlciAodGhlcmUgaXMgZmxvYXRpbmcgYXJvdW5kLCBp dCdzIGp1c3Qgb2xkKSBhbmQKPiA+IHdlIGNvdWxkIGZvcmdldCBhYm91dCBhbnkgcmVhbCBmYmRl diBkcml2ZXJzIGV4Y2VwdCB0aGUgZHJtIGJhc2VkCj4gPiBvbmVzLgo+IAo+IEFuZCBkcm1jb24s IHVubGVzcyB3ZSBjb21lIHVwIHdpdGggYSBiZXR0ZXIgaWRlYSB0aGFuIGhvb2tpbmcgaW50byB0 aGUgKmNvbiBkcml2ZXIuCgpJZiB3ZSBoYXZlIGV2ZXJ5dGhpbmcgYXMgZHJtIGRyaXZlcnMsIHlv dSBjYW4ganVzdCB1c2UgcGx5bW91dGggKHdpdGggbm8KZmJkZXYgYmFja2VuZCBvZmMpIGFuZCBl dmVyeW9uZSBpcyBoYXBweS4gSW5jbHVkaW5nIHRoZSBlZmlmYiBmb2xrcyAoaXQncwpzaW1wbHkg Z29pbmcgdG8gYmUgY2FsbGVkIGVmaWRybWZiIG9yIHNvbWV0aGluZyBsaWtlIHRoYXQpLiBTbyBu byBpZGVhIHdoeQp5b3UgbmVlZCBhICpjb24uCgo+IFN1cmUsIHRoYXQnZCBoZWxwIGEgbG90LiBC dXQgd2hhdCBkbyB3ZSBkbyB1bnRpbCB0aGVuPwoKTWFrZSBpdCBoYXBwZW4/IFR3aWRkbGluZyB0 aHVtYnMgaXMgYW4gb3B0aW9uIHRvbyBvZmMsIGJ1dCBpdCB0ZW5kcyB0byBub3QKcmVzdWx0IGlu IHJlc3VsdHMgOi0pCgpDaGVlcnMsIERhbmllbAotLSAKRGFuaWVsIFZldHRlcgpTb2Z0d2FyZSBF bmdpbmVlciwgSW50ZWwgQ29ycG9yYXRpb24KaHR0cDovL2Jsb2cuZmZ3bGwuY2gKX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVsIG1haWxpbmcg bGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRl c2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg==