Re: Look Ma, da kernel is b0rken

[Andreas Mohr]

Hi,

On Wed, Dec 05, 2012 at 03:27:56PM +0000, Alan Cox wrote:
> > On Wed, Dec 05, 2012 at 08:09:01AM +0100, Andreas Mohr wrote:
> > > Hi,
> > > 
> > > drivers/pnp/pnpacpi/core.c: In function 'ispnpidacpi':
> > > drivers/pnp/pnpacpi/core.c:65:2: warning: logical 'or' of collectively
> > > exhaustive tests is always true [-Wlogical-op]
> > > drivers/pnp/pnpacpi/core.c:66:2: warning: logical 'or' of collectively
> > > exhaustive tests is always true [-Wlogical-op]
> > > drivers/pnp/pnpacpi/core.c:67:2: warning: logical 'or' of collectively
> > > exhaustive tests is always true [-Wlogical-op]
> > > 
> > > 
> > > That's already the second less enticing -Wlogical-op issue
> > > which was discovered by accident during less than two days
> 
> No it's not. It's been reported in bugzilla. I sent patches ages ago.
> They were ignored. Coverity has had it tagged for years (and a ton more
> of them you've not noticed yet)

And that additional new info bit now arriving
is supposed to improve on the total set of the general state of affairs
as I'm observing it (and thus to appease me, sufficiently), how exactly? ;)
(well, admittedly it was new to me since I didn't bother with doing
any more research after discovering that bug
after also having endured countless pages of dangerously obscuring
completely *superfluous* warning spew scrolling by)

Let's see:

- we've got this *core layer* (right?) bug
  originally appearing in <= 2.6.10 (2004, i.e. 8+ years).
- we've got a janitorial project which does not (possibly "cannot"?)
  do a sufficiently clean work (as evidenced by a metric crap ton of
  header-side woefully repeated warnings persisting over perhaps half a year
  in my observation, with W=2 or W=3)
- we've got how many dozen dozen kernel maintainers or "interested" persons
  who I'd imagine would be a sure-fire method to get such issues fixed
  in due time, and how many distributors or embedded companies
  who I'd imagine would help towards doing a quite large amount of effective
  testing/verification/housekeeping work in a controlled manner?
  (which would include regularly/mechanically keeping an eye
  on a larger set of *non-default* compiler warnings, too)
- we've got how many kernel-related tools to assist in such efforts,
  which then were not being followed sufficiently? [Coverity]
- and now your reply seems to indicate we additionally have
  a less optimal response time for such fixes, too?


If that isn't a strong indicator of having to spend some time on
rethinking possibly automated kernel development core infrastructure
or due process...


Heck, the Linux kernel isn't a "Joe's Garage works" effort -
it's a *very* widely used *very* public project, thus you'd think
with its clout and resulting manpower
it should be able to easily afford things such as near-eradication of warnings
(and thus the resulting much improved precision in *successfully* letting
mere users pinpoint single critical warnings as near-soon as they newly appear, due to a low amount of warnings even on a high warning level).


I'm afraid even with my measly very specific project/laughable manpower
I've got certain parts in place which go beyond of what the kernel
chooses to use.


As an additional factor, the C-based kernel has the convenience of
not even having to spend effort on the large set
of additional compiler warnings that the developer is gifted with in C++ space!


For gcc -Wlogical-op, it seems many articles/discussions were in 2009 time,
thus there admittedly probably wasn't such a large window of opportunity
to get this bug discovered - however that's still no excuse for the very
visible showering of simple warnings when enabling advanced levels.


Thanks to Borislav Petkov for his reply, too -
however I'd like to state that given this lack of tooling/attention
writing a mail in this more special manner was fully justified IMPHO.

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