On Mon, Jan 26, 2015 at 09:34:19PM -0500, Steven Rostedt wrote: > On Mon, 26 Jan 2015 18:37:39 -0500 > Steven Rostedt <rost...@goodmis.org> wrote: > > > > > the first call of tracing_init_dentry(). Prior to that it's NULL. > > > BTW, may I politely inquire what the fuck are those contortions in > > > tracing_init_dentry_tr() about? Looks like a stunningly convoluted > > > way to trigger that automount point creation early in > > > tracer_init_tracefs(). Why not do that right there explicitly? > > > > Yeah, that could be cleaned up. Before the tracefs code, it made much > > more sense to keep that as a single function. Now that > > global_array.dir is treated differently as the subdirs, it does make > > sense to have global_arry.dir initialized in a separate function. > > > > I'll update my patch series to do this. > > Now I remember why I did this (as I changed the code and everything > blew up). The files in the tracing directory can be created by several > users (do a grep for fs_initcall() in kernel/trace/*.c). The first > caller to add a file initializes the tracing directory. > > I guess I can have all the other callers use fs_initcall_sync(). I'm > assuming those come after fs_initcall().
Ah... That explains some of the oddities of that kind (not all of them, though - your trace_options_init_dentry() is called by create_trace_option_dirs() and create_trace_option_core_file(), which is called only by create_trace_option_dirs(), and that - quite a few times, each time calling trace_options_init_dentry()). Strange style, IMO. Frankly, I'd rather have the ordering as explicit as it gets... -- 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/
