(adding lkml as this is likely better discussed there) On Thu, 2015-12-03 at 15:42 -0500, Jason Baron wrote: > On 12/03/2015 03:24 PM, Joe Perches wrote: > > On Thu, 2015-12-03 at 15:10 -0500, Jason Baron wrote: > > > On 12/03/2015 03:03 PM, Joe Perches wrote: > > > > On Thu, 2015-12-03 at 14:32 -0500, Jason Baron wrote: > > > > > On 12/03/2015 01:52 PM, Aaron Conole wrote: > > > > > > I think that as a minimum, the following patch should be evaluted, > > > > > > but am unsure to whom I should submit it (after I test): > > > > [] > > > > > Agreed - the intention here is certainly to have no side effects. It > > > > > looks like 'no_printk()' is used in quite a few other places that would > > > > > benefit from this change. So we probably want a generic > > > > > 'really_no_printk()' macro. > > > > > > > > https://lkml.org/lkml/2012/6/17/231 > > > > > > I don't see this in the tree. > > > > It never got applied. > > > > > Also maybe we should just convert > > > no_printk() to do what your 'eliminated_printk()'. > > > > Some of them at least. > > > > > So we can convert all users with this change? > > > > I don't think so, I think there are some > > function evaluation/side effects that are > > required. I believe some do hardware I/O. > > > > It'd be good to at least isolate them. > > > > I'm not sure how to find them via some > > automated tool/mechanism though. > > > > I asked Julia Lawall about it once in this > > thread: https://lkml.org/lkml/2014/12/3/696 > > > > Seems rather fragile to have side effects that we rely > upon hidden in a printk(). Yup. > Just convert them and see what breaks :) I appreciate your optimism. It's very 1995. Try it and see what happens. -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
