Hi, On Thursday, June 22, 2017 03:48:34 PM Daniel Vetter wrote: > On Thu, Jun 22, 2017 at 3:42 PM, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > > Tears pretty much guaranteed, and after a few hacks from Alan&me I > > concluded that the only way to fix this is to at least partially > > rewrite fbdev (a dead subsystem, so no one's volunteering), with the > > risk that you get to revert it all because someone is indeed relying > > on that super-flexible module loading order sequence. The simplest fix > > would probably be to make the entire fbdev->fbcon setup depency a > > hard-coded function call, or maybe at most a one-shot symbol_get > > attempt. > > I did once hash out a plan how to fix this with the least amount of pain: > > 1. Merge a patch to build the fbcon support into the overall fb.ko > module, so that the dynamic loading nonsense is essentially disabled, > and fbcon becomes a Kconfig/compile-time only option, no longer a > runtime-selectable thing. > > 2. Wait 1 year and pray that no one reports a regression. If you're > unlucky, try to fence them of with a runtime option to disable fbcon. > > 3. Rip out the notifier nonsense and replace it by direct function > calls. You can only do that once 1. won't be reverted anymore. > > 4. Push the console_lock donw the callchains until it's again at the > right spots, auditing all the other stuff meanwhile to make sure the > locking is still correct. > > 5. Apply your patch to make console_lock sane. > > Adding fbdev maintainers and lists just. Your plan sounds good to me. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
