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
prev 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).