linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Krzysztof Halasa <khc@pm.waw.pl>
Cc: linux-fbdev-devel@lists.sourceforge.net,
	Jeff Garzik <jeff@garzik.org>,
	adaplas@gmail.com, LKML <linux-kernel@vger.kernel.org>,
	ak@suse.de, Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [git patches] two warning fixes
Date: Sat, 21 Jul 2007 10:32:53 +1000	[thread overview]
Message-ID: <1184977973.5439.45.camel@localhost.localdomain> (raw)
In-Reply-To: <m3644e2abd.fsf@maximus.localdomain>

On Fri, 2007-07-20 at 20:34 +0200, Krzysztof Halasa wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
> 
> > More people *should* generally ask themselves: "was the warning worth it?" 
> > and then, if the answer is "no", they shouldn't add code, they should 
> > remove the thing that causes the warning in the first place.
> 
> Sure. If a routine uses must_check yet its return value may be
> safely ignored then that must_check is simply misplaced and should
> be removed. It does not mean all must_checks are bad - each of them
> isn't bad unless one can demonstrate it is.
> 
> Back to sysfs_create_bin_file() - if one can demonstrate a caller
> can safely ignore the return value (which, it seems, is the
> case), then exactly this very must_check should be removed

Typically, the EDID creation in radeonfb :-)

In fact, I'm not even sure there's -any- user of those sysfs files. I
added them back then to allow distros to extract the EDID infos that
were probed by radeonfb to properly configure the X server (because on
some machines, the EDID is coming from the firmware/BIOS, not from DDC,
and X can't get at it). I don't know if they ever used them.

In any case, it doesn't make sense to abort initialization of the driver
if for some reasons those files can't be created (for example, the core
fbdev starts exposing EDID files, radeonfb isn't properly updated, name
clash, error). Aborting the initialization will make sure that on some
machines such as powermacs with radeon, whatever error is displayed will
never be seen by the user.

That's a typical, but I have plenty more.

For example, the powermac thermal control drivers. They work pretty well
by themselves. They also expose via sysfs all the current values, fan
speeds, temps ,etc... for the sake of whoever wants to do a GUI or
"monitor" what's going on, but that is not critical to the operation of
the driver. Thus, failure to create those files is not critical.

I have plenty other examples.

Thus, we have two choices here:

 - The simple one: sysfs_create_blah() displays a warning when it fails
and has no must_check

 - The one that adds code everywhere (the current one):
sysfs_create_blah() returns an error, has much_check, and thus all
callers like I described abvoe need to add code to test it and print a
warning. Lots of added .text and .data for little benefit.

Cheers,
Ben.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

  reply	other threads:[~2007-07-21  0:33 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-18 23:55 [git patches] two warning fixes Jeff Garzik
2007-07-18 23:59 ` Andi Kleen
2007-07-19  0:05   ` Jeff Garzik
2007-07-19  1:19     ` Benjamin Herrenschmidt
2007-07-19  1:41       ` Andrew Morton
2007-07-19  1:50         ` Linus Torvalds
2007-07-19  2:05           ` Benjamin Herrenschmidt
2007-07-19  2:36           ` Andrew Morton
2007-07-19  1:37 ` Linus Torvalds
2007-07-19  2:32   ` Jeff Garzik
2007-07-19 13:40     ` Krzysztof Halasa
2007-07-19 18:04       ` Linus Torvalds
2007-07-19 18:20         ` Stephen Hemminger
2007-07-20 18:34         ` Krzysztof Halasa
2007-07-21  0:32           ` Benjamin Herrenschmidt [this message]
2007-07-22  4:03             ` Jeff Garzik
2007-07-22 21:29               ` Benjamin Herrenschmidt
2007-07-23  3:26         ` Kyle Moffett
2007-07-19 13:38   ` Krzysztof Halasa
2007-07-19 18:00     ` Linus Torvalds
2007-07-20 12:54       ` Tim Tassonis

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=1184977973.5439.45.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=adaplas@gmail.com \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=jeff@garzik.org \
    --cc=khc@pm.waw.pl \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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).