On Wed, 01 Sep 2010 22:07:29 -0700 Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: > 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. > Fair enough. We're splitting hairs at this point. Let's just take this as-is. For v5 of the patch: Acked-by: Jeff Layton <jlayton@xxxxxxxxx> -- 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
