Hi -
>> From: Steven Rostedt <rost...@goodmis.org> >> >> Tracepoints were made to allow enabling a tracepoint in a module before that >> module was loaded. When a tracepoint is enabled and it does not exist, the >> name is stored and will be enabled when the tracepoint is created. >> >> The problem with this approach is that when a tracepoint is enabled when >> it expects to be there, it gives no warning that it does not exist. So it is a deferred-activation kind of call, with no way of knowing when or if the tracepoints will start coming in. Why is that supported at all, considering that clients could monitor modules coming & going via the module_notifier chain, and update registration at that time? >> + entry = get_tracepoint(name); >> + /* Make sure the entry was enabled */ >> + if (!entry || !entry->enabled) >> + ret = -ENODEV; For what it's worth, I agree with Mathieu that this sort of successful failure result code is a problem for tracking what needs cleanup and what doesn't. (In systemtap's case, if this change gets merged, we'll have to treat -ENODEV as if it were 0.) - FChE -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
