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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.