lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 02 Feb 2015 20:13:10 +0100
From:	Andreas Ruprecht <rupran@...server.de>
To:	Al Viro <viro@...IV.linux.org.uk>
CC:	Oleg Drokin <oleg.drokin@...el.com>,
	Andreas Dilger <andreas.dilger@...el.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	HPDD-discuss@...1.01.org, devel@...verdev.osuosl.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: lustre: osc: Fix sparse warning about osc_init

On 02.02.2015 15:16, Al Viro wrote:
> On Mon, Feb 02, 2015 at 02:36:43PM +0100, Andreas Ruprecht wrote:
>> When running sparse on the osc/ subdirectory, it shows the
>> following warning:
>>
>> andreas@...kbox:~/linux-next$ make C=1 M=drivers/staging/lustre/lustre/osc/
>> [...]
>> drivers/staging/lustre/lustre/osc/osc_request.c:3335:12: warning:
>> symbol 'osc_init' was not declared. Should it be static?
>> [...]
>>
>> As this is the module init function, it can (and should) be declared
>> static.
>>
>> Signed-off-by: Andreas Ruprecht <rupran@...server.de>
> 
> For pity sake, folks, could you at least try to produce less meaningless
> commit summaries?  "Fix sparse warning" says nothing whatsoever about
> what's getting done.  The role of sparse in that is simple - it has
> provided a tip to look at that declaration.  That's all; it might as well
> had been offered by a guy puking at the next stall in the loo after big
> party.  And no, sparse alone is not sufficient to prove that it could be
> made static - it might be used somewhere else with explicit extern, its
> declaration might've been in a header that didn't get included here, or
> under slightly incorrect ifdefs, etc.  Such things need to be investigated
> manually, not that it was hard to do.  OK, in this case the tip had panned
> out; it can be made static (quick grep shows that) and it's better off
> that way - less namespace pollution, makes life easier when doing analysis
> of that code, etc.
> 
> _That_ is the point of this patch, not making the holy oracle shut the bleeding
> fuck up.  If you want to credit sparse (or that guy puking in the next stall,
> or whatever had drawn your attention to the function in question) - great,
> do so inside the commit message.  _AFTER_ having described what the patch
> does ("make osc_init() static" or equivalent thereof), please.  Ideally -
> with something like "it's never used outside of osc_request.c" after summary
> line (strictly speaking, something that serves as module_init might very well
> be called elsewhere in the module explicitly; not common, but possible).
> 

... and a very nice day to you, too, sir!

On a serious note: I do understand what you're getting at, I don't take
that personally (and I will send a v2 addressing the things above), but
honestly, this kind of answer might just be a real turn-off for other
people trying to get into kernel development...

I don't want to start a whole new 'attitude in the kernel community'
discussion, but I can't just let this go like that, sorry.

Regards,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ