On Thu, May 25, 2017 at 8:54 AM, SF Markus Elfring <elfring@xxxxxxxxxxxxxxxxxxxxx> wrote: >>> 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? Does kmalloc() nowadays print a message which invocation (source line) failed? If so I won't be standing in your way, but if not, you need to come up with something for convincing than answering questions with more questions. Manuel -- 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
