linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: linux-fbdev@vger.kernel.org
Subject: Re: [PATCH 9/10] udlfb: explicit dependencies and warnings
Date: Fri, 19 Feb 2010 00:37:26 +0000	[thread overview]
Message-ID: <20100219003724.GC29873@suse.de> (raw)
In-Reply-To: <1266245195.4353.3304.camel@bernie-aspireone>

On Thu, Feb 18, 2010 at 02:49:34PM -0800, Bernie Thompson wrote:
> Hi Greg,
> 
> On Thu, Feb 18, 2010 at 8:01 AM, Greg KH <greg@kroah.com> wrote:
> > This patch adds the warning to the build:
> >        drivers/staging/udlfb/udlfb.c:65:2: warning: #warning message "FB_SYS_* in kernel or module option to support fb console"
> 
> The intent is you'd get that warning when:
> 
> * You're building udlfb as a module outside of full kernel rebuild
> * You don't have a dependency you need (for full functionality)
> 
> If you were doing a full kernel build, Kconfig (as of this patch)
> knows the dependencies as should pull them in.
> 
> In this case, your kernel headers say you don't have
> CONFIG_FB_SYS_IMAGEBLIT (which is part of the "virtual framebuffer
> driver" ops set of BLIT, FILL, etc. which has a lot of (IMHO
> incorrectly strong) warnings around it in Kconfig not to enable, since
> several drivers are now dependent.
> 
> That dependency is needed for framebuffer consoles (fbcon) to work
> properly in udlfb with the current implementation. This post gives a
> little background on the different types of framebuffer clients:
> http://plugable.com/2010/01/30/linux-kernel-framebuffer-rendering-apis/
> 
> So you either need to recompile your kernel to get this dependency, or
> live without framebuffer console functionality (which many people
> don't care about -- but some do a lot).
> 
> Failing compile completely generated a strong response from some users
> -- they didn't want to recompile their whole kernel to get a single
> module, if the dependency was for functionality they didn't care
> about.
> 
> Keeping the #ifdefs but getting rid of the #warnings would mean
> silently loosing functionality, which would throw people off later.
> 
> So two questions:
> * Is there evidence the #warning is getting triggered in a case where
> it shouldn't (you actually have the dependency)?
> * Does the wording of the #warning need to be better - any suggestions
> for future patches?

I must have done something wrong, built only the drivers/staging/udlfb/
directory or something, with a full kernel build I no longer see this
issue.

Very sorry for the noise, and thanks for the full response.

greg k-h

      parent reply	other threads:[~2010-02-19  0:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-15 14:46 [PATCH 9/10] udlfb: explicit dependencies and warnings Bernie Thompson
2010-02-18 16:01 ` Greg KH
2010-02-18 22:49 ` Bernie Thompson
2010-02-19  0:37 ` Greg KH [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100219003724.GC29873@suse.de \
    --to=gregkh@suse.de \
    --cc=linux-fbdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).