Re: [PATCH] Illustration of warning explosion silliness
From: Andrew Morton
Date: Wed Sep 27 2006 - 23:35:30 EST
On Wed, 27 Sep 2006 21:48:42 -0400
Jeff Garzik <jeff@xxxxxxxxxx> wrote:
> The usage model should not be _forced_ upon the caller, since it might
> not be needed.
IMO: tough titty.
This isn't some random crappy perl script. Nor is it even some random
crappy sound card driver. This is our scsi stack. The heart of our
system. Picture yourself telling a Fortune 100 CTO why his kernel is
cheerily discarding errors (and hence his reliability and possibly data)
all over the place. Take a peek at spi_dv_device() and its callees...
I was astonished at the number of ignored errors all over the
sysfs/driver-model code. And that's only there to detect programming
errors. That's nothing compared to these bugs.
Discarding already-detected hardware or software errors in the storage
stack is toe-curlingly lame, and completely trumps the inconvenience of
developers seeing a few warnings, or having to put artificial warning
shutter-uppers in a few places.
Now I'm sure I'm about to be flooded with long-winded explanations about
why all of this can never happen. But y'know what? I don't care.
Hardware errors can sometimes happen. As can programming errors, as can
memory-corruption and dropped-bit errors and all the other things we
regularly see. The kernel should be robust in the presence of unexpected
events. *Particularly* those parts which are handling storage. Any
void-returning function in a driver or a mid-layer is a huge red flag.
And it's not sufficient to say "gee, I can't think of any reason why this
handler would return an error, so I'll design its callers to assume that".
It is _much_ better to design the callers to assume that callees _can_
fail, and to stick the `return 0;' into the terminal callee. Because
things can change.
There, I feel better now. If you want to see the other warnings, set
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/