mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Pranith Kumar <pranith.hacks@gmail.com>
Cc: Greg KH <greg@kroah.com>, linux-kernel@vger.kernel.org
Subject: Re: Are patches for warnings in drivers/staging/* worth?
Date: Fri, 05 Jun 2009 13:20:22 +0200	[thread overview]
Message-ID: <4A28FF76.7050104@s5r6.in-berlin.de> (raw)
In-Reply-To: <4A28B566.1010105@gmail.com>

Pranith Kumar wrote:
> Hi Greg,
> 
> I am looking at the various warnings which occur while compiling the 
> staging drivers. Most of them are
> 
> * unused variables
> * arg makes pointer from integer without cast
> * un-initialized variable
> 
> What in these warnings should I send patches against?

I'm not Greg, but --- I'd say it's the same as with all other kernel code:

  - If somebody else already actively works on the code in question,
    coordinate your efforts with him.  (I suppose Greg as the maintainer
    will tell you if there is parallel effort and whether /he/ will
    merge your patches, or the other developer should pick them up, or
    whatever.)¹

  - The goal of such patches should not just be about making the
    warnings go away, they should be about improving the code:  Fix
    bugs, make it more readable, eventually optimize...  I for one agree
    with the people who say that "fixing" the warnings without
    addressing the /underlying/ problems or even just the /surrounding/
    problems is actually very counterproductive.  Warnings are good!²
    They tell us that there probably is a problem.  As long as the
    problem is there, the warning should stay there.

> Are they worth the effort?

Most certainly, because getting the drivers merge-ready is exactly the
main purpose of carrying them in the staging area.


¹) For coordination between those who work on the staging drivers, there
is also linuxdriverproject.org's devel mailinglist.

²) Well, warnings are /not/ good if they become overwhelming noise.  But
at least the staging drivers are out of the picture of normal kernel
configurations, therefore they normally don't add noise.
-- 
Stefan Richter
-=====-==--= -==- --=-=
http://arcgraph.de/sr/

  reply	other threads:[~2009-06-05 11:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-05  6:04 Pranith Kumar
2009-06-05 11:20 ` Stefan Richter [this message]
2009-06-05 17:41 ` Greg KH

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=4A28FF76.7050104@s5r6.in-berlin.de \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pranith.hacks@gmail.com \
    /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

all inboxes | Powered by JetHome®