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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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
