Messages in this thread | | | Subject | Re: [RFC PATCH v2 00/13] Kernel based bootsplash | From | Max Staudt <> | Date | Wed, 20 Dec 2017 15:10:54 +0100 |
| |
On 12/20/2017 10:43 AM, Daniel Vetter wrote: > On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote: >> On 12/19/2017 06:26 PM, Daniel Vetter wrote: >>> 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.
Sorry, I was unclear.
It's Plymouth's ShowDelay that, unintentionally, papers over this bug.
The driver loading bug will happen with any user based splash - it's not limited to Plymouth.
On the other hand, if you don't start a graphical application before having loaded the final graphics driver, everything is good and there is no race.
So, module loading works as intended ;)
>>> 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.
Hmm. Are you sure it's okay to SIG these processes just because someone else has decided to unload a driver? That is counter to everything else that I've seen so far.
Also, is it even feasible, implementation wise?
>>> 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.
Hmm, that still makes us wait until userspace has appeared...
And the reason I built it into *con is because the logic for appearing/disappearing is basically the same, and in this chain it makes sense for the bootsplash show/hide logic to be chained behind *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 :-)
I'm afraid I don't have the time to write an in-kernel terminal emulator, thus the wish to build upon the existing one...
| |