On Mon, 26 Mar 2018 11:39:05 -0700 Alexei Starovoitov <ast@xxxxxx> wrote: > On 3/26/18 11:11 AM, Steven Rostedt wrote: > > On Mon, 26 Mar 2018 10:55:51 -0700 > > Alexei Starovoitov <ast@xxxxxx> wrote: > > > >> An email ago you were ok to s/return/return NULL/ in your out-of-tree > >> module, but now flip flop to add new function approach just to > >> reduce the work you need to do in lttng? > >> We're not talking about changing __kmalloc signature here. > >> My patch extends for_each_kernel_tracepoint() api similar to other > >> for_each_*() iterators and improves possible uses of it. > > > > Alexei, do you have another use case for using > > for_each_kernel_tracepoint() other than the find_tp? If so, then I'm > > sure Mathieu can handle the change. > > > > But I think it's cleaner to add a tracepoint_find_by_name() function. > > If you come up with another use case for using the for_each* function > > then we'll consider changing it then. > > another use case ?! Frankly such reasoning smells. WTF is the big deal here? > > I'm fine doing quick followup patch to add tracepoint_find_by_name() And BTW, it would actually have to be called tracepoint_core_find_by_name() as it will not deal with modules. Modules would have to have much more work to deal with. > and restore 'return void' behavior of for_each_kernel_tracepoint's What? you can't rebase now? Just don't touch that function. > callback, but I'm struggling to accept the precedent it will create > that all exported functions of kernel/tracepoint.c are really > lttng extensions and we cannot easily change them. First, my argument about your use case has little to do with LTTng. I have to maintain this code, and this is my preference. Just like I do the silly /* Comment like this, * for multiple lines */ When I deal with the networking code. Because that's the preference for the networking folks. > I'd like to hear Linus take on this. I doubt he cares about something this petty. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
