On Thu, 1 Feb 2018, SF Markus Elfring wrote: > >> The function "kmem_cache_alloc" was specified despite of the technical > >> detail that this function does not get a parameter passed which would > >> correspond to such a size information. > >> > >> Thus remove it from the first two SmPL rules and omit the rule "r4". > > > > Nack. > > I find such a rejection surprising once more. > > > > It should be supported by the size determined in another way. > > I am curious on how our different views could be clarified further > for this special software situation. > > * Do we agree that a proper size determination is essential for every > condition in the discussed SmPL rules together with forwarding > this information? No. I don't mind a few false positives. The user can look at the answer and see if it is a false positive or not. Furthermore, I told you how to address this function so that the size issue would be taken care of. That is the patch that I would accept. > > * How can a name be ever relevant (within the published SmPL approach) > for a function when it was designed in the way that it should generally > work without a size parameter? No idea what this means. julia -- 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
