From: "Kay Sievers" <kay.sievers@vrfy.org>
To: "Vorobiev Dmitri" <dmitri.vorobiev@movial.fi>
Cc: "James Bottomley" <James.Bottomley@hansenpartnership.com>,
linux-scsi@vger.kernel.org, linux-mips@linux-mips.org,
"Greg KH" <greg@kroah.com>
Subject: Re: [PATCH] SCSI: fix the return type of the remove() method in sgiwd93.c
Date: Wed, 3 Dec 2008 19:51:15 +0100 [thread overview]
Message-ID: <ac3eb2510812031051k9d9312bma119bfae35afc230@mail.gmail.com> (raw)
In-Reply-To: <35647.88.114.226.209.1228329736.squirrel@webmail.movial.fi>
On Wed, Dec 3, 2008 at 19:42, Vorobiev Dmitri <dmitri.vorobiev@movial.fi> wrote:
>> On Wed, 2008-12-03 at 18:52 +0100, Kay Sievers wrote:
>>> On Wed, Dec 3, 2008 at 18:08, James Bottomley
>>> <James.Bottomley@hansenpartnership.com> wrote:
>>> > On Wed, 2008-12-03 at 18:24 +0200, Vorobiev Dmitri wrote:
>>> >> > This patch fixes the following compilation warning:
>>> >> >
>>> >> > CC [M] drivers/scsi/sgiwd93.o
>>> >> > drivers/scsi/sgiwd93.c:314: warning: initialization from
>>> incompatible
>>> >> > pointer type
>>> >>
>>> >> Any news about this one? I think this patch should go via linux-scsi,
>>> >> unless you would be insisting on pushing it via linux-mips, in which
>>> case
>>> >> I'll politely bug Ralf about it. :)
>>> >
>>> > Looks OK for the local change.
>>> >
>>> > Globally, having driver->remove and platform_driver->remove return int
>>> > instead of void looks wrong. Particularly when the only use cases are
>>> > in drivers/base/ and they all ignore the return code.
>>> >
>>> > Greg and Kay ... shouldn't we simply redefine the return values for
>>> the
>>> > remove methods in these structures to return void (and thus match the
>>> > use case)?
>>>
>>> Aren't there many many drivers across the tree, using the "int remove"
>>> version?
>>
>> Yes ... since it's a function prototype.
>>
>> However, if drivers/base simply discards the return, it's a trap we
>> shouldn't be setting.
>
> Hmmm, it does look like the return value is discarded, please see
> drivers/base/dd.c::__device_release_driver() for details.
>
> Does this not deserve a good cleanup?
Sure, it might be. If you want to patch hundreds of files, send
patches to maintainers, patch drivers you can not even compile, we
could do that.
We are already in the middle of a ~400 files "struct device" bus_id
conversion, and only very few maintainers respond to these patches. We
also never got any reply to the SCSI bus_id patch we sent weeks ago.
:)
Even when it's "a good cleanup", with maintainers not responding, and
supporting it, it's a real pain to change things like this. But, if
you want to go ahead and do that, let us know.
Kay
next prev parent reply other threads:[~2008-12-03 18:51 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-20 0:19 [PATCH] SCSI: fix the return type of the remove() method in sgiwd93.c Dmitri Vorobiev
2008-12-03 16:24 ` Vorobiev Dmitri
2008-12-03 16:24 ` Vorobiev Dmitri
2008-12-03 17:08 ` James Bottomley
2008-12-03 17:08 ` James Bottomley
2008-12-03 17:52 ` Kay Sievers
2008-12-03 18:01 ` James Bottomley
2008-12-03 18:42 ` Vorobiev Dmitri
2008-12-03 18:42 ` Vorobiev Dmitri
2008-12-03 18:51 ` Kay Sievers [this message]
2008-12-03 19:00 ` James Bottomley
2008-12-03 20:29 ` Kay Sievers
2008-12-03 20:52 ` James Bottomley
2008-12-03 20:59 ` Kay Sievers
2008-12-03 21:02 ` James Bottomley
2008-12-03 21:28 ` Kay Sievers
2008-12-03 21:33 ` James Bottomley
2008-12-03 21:41 ` Kay Sievers
2009-01-02 16:25 ` James Bottomley
2009-01-02 16:31 ` Kay Sievers
2009-01-02 16:32 ` James Bottomley
2008-12-03 19:07 ` Vorobiev Dmitri
2008-12-03 19:07 ` Vorobiev Dmitri
2008-12-03 19:10 ` Vorobiev Dmitri
2008-12-03 19:10 ` Vorobiev Dmitri
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=ac3eb2510812031051k9d9312bma119bfae35afc230@mail.gmail.com \
--to=kay.sievers@vrfy.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=dmitri.vorobiev@movial.fi \
--cc=greg@kroah.com \
--cc=linux-mips@linux-mips.org \
--cc=linux-scsi@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