>> How do you think about to achieve a small code reduction also for this software module? > > Generally speaking, sure. Thanks for your interest in such a direction. > But why remove just this one? Is it because it loosely follows a > pattern that was deemed removable in that slidedeck you linked to? I derived another source code search approach from the implementation of the check “OOM_MESSAGE” in the script “checkpatch.pl” for the semantic patch language (Coccinelle software). The involved search patterns are still evolving and the used lists (or regular expressions) for function names where it might make sense to reconsider the usage of special logging calls is therefore incomplete. > (the "usb_submit_urb()" part)? Would you like to extend the function selection for further considerations? >> Do you find information from a Linux allocation failure report sufficient >> for such a function implementation? > > Yes, I wrote that code, and in case this driver doesn't load, I'd like > to know precisely where initialization failed. > I can happily spare a few bytes for that. Does this kind of answer contain a bit of contradiction? * Why do you seem to insist on another message if information from a Linux allocation failure report would be sufficient already also for this software module? * Do you want that it can become easier to map a position in a backtrace to a place in your source code? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
