On 09/01/2010 05:38 PM, Jeff Layton wrote:
No warning, it always returns something since the default case catches
all others. If I did put the return at the end, then the compiler wouldn't
catch a case where I forgot to return from one of the case statements,
but it's not overly complex code, so I don't care so much either way.
Plz let me know if you still want it at the end.
I also think the WARN_ON is valid, because it can only be a coding bug
that hits that state, and I'd like it to be as loud as possible while
still allowing the user to continue. There are automated tools that
catch WARN_ON output and post to kernel bug trackers, for instance.
If you still want a cERROR, I can do that..but I prefer to not waste
the space.
It's definitely a coding bug if that fires, but a WARN_ON will mean
nothing to users. It looks scary and is virtually indistinguishable
from an oops. We'll get a stack trace, but it's unlikely to tell us
much.
At that point, you might as well make it a BUG(). At least that way,
we might get a core dump if it fires.
I'd like to wrap this up. Please let me know exactly what you want there
and I'll make it so.
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
