From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0AEC8504 for ; Tue, 27 Jun 2017 13:06:34 +0000 (UTC) Received: from mail-pf0-f195.google.com (mail-pf0-f195.google.com [209.85.192.195]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E88B53CC for ; Tue, 27 Jun 2017 13:06:32 +0000 (UTC) Received: by mail-pf0-f195.google.com with SMTP id e199so4714692pfh.0 for ; Tue, 27 Jun 2017 06:06:32 -0700 (PDT) Date: Tue, 27 Jun 2017 22:06:39 +0900 From: Sergey Senozhatsky To: Bartlomiej Zolnierkiewicz Message-ID: <20170627130639.GA1886@jagdpanzerIV.localdomain> References: <20170619052146.GA2889@jagdpanzerIV.localdomain> <10423619.jNvHD4M0jW@amdc3058> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10423619.jNvHD4M0jW@amdc3058> Cc: "ksummit-discuss@lists.linuxfoundation.org" , Linux Fbdev development list Subject: Re: [Ksummit-discuss] [TECH TOPIC] printk redesign List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On (06/23/17 11:07), Bartlomiej Zolnierkiewicz wrote: > On Thursday, June 22, 2017 03:48:34 PM Daniel Vetter wrote: > > On Thu, Jun 22, 2017 at 3:42 PM, Daniel Vetter 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. cool. I'm willing to help. let's coordinate. -ss