Messages in this thread | | | Date | Wed, 22 Apr 2015 13:00:52 -0400 | From | Steven Rostedt <> | Subject | Re: [PATCH] tracing: Export key trace event symbols |
| |
On Wed, 22 Apr 2015 11:35:41 -0500 Ron Rechenmacher <ron@fnal.gov> wrote:
> With the understanding, as has been mentioned before, that "only the user space ABI is > what we keep stable" and that before commit de7b2973903c (tracepoint: Use struct pointer > instead of name hash for reg/unreg tracepoints) it was just "lucky" that I could use > the register_tracepoint_* routines as somewhat generic "add hook" routines (from > external modules), is it now reasonable to accept my patch to allow external modules > to "add hooks" to key events in Linux? Why or why not? >
As has been mentioned before, the EXPORT_SYMBOL*() calls is for in-tree modules that need them. If there's no in-tree users of the exported symbol, that can be grounds for removing them.
But that is more of a guideline than a rule. Preferably, we want people using the in-tree mechanisms, because as I have said before, if something is useful for you, it is most likely useful for others. Even if it is your own home grown utility. You've been keeping it around for 30 years and that says something. It means that it is probably useful for other people as well.
We resist making small changes for out-of-tree modules because we want that functionality in tree. Now, if for some reason, we agree that the functionality does not belong in tree, and all maintainers involved are OK, we can add a hook for you. But that wont happen until we are convinced that the functionality you want belongs out of tree and the in tree mechanisms are not good enough for you.
I'll admit it adds more burden on you. But the net goal of Linux kernel development is not it improve usability for each individual, but to improve the infrastructure as a whole, such that the community benefits in the end, and not just for a few individuals. Yes, it takes more time, thought and effort, but in the long run, it's a net gain for everyone (including you :-).
-- Steve
| |