On Tue, 2013-01-22 at 20:08 -0800, Greg Kroah-Hartman wrote: > > Is doing something as silly as the following fine, or is there a better > > way? > > Yes, why not create your own fs for ftrace? :) But but but... debugfs is soooo convenient! Do you think it would be worth doing that though? I only need the mkdir and rmdir for this one instance. Nothing more. > > mutex_unlock(&inode->i_mutex); > > > > ret = new_instance_create(dentry->d_iname); > > > > mutex_lock(&inode->i_mutex); > > > But how can you callback to your code to let it know that something was > created in it? I pass the dentry->d_iname to create a directory. > > Don't you need that for both mkdir and rmdir? It's a global list. It's very specific and doesn't need to be robust. It all deals with modifying one global parameter. Not that hard. And I've already implemented this. It works quite well :-) > > But again, I'd really not want to do this in debugfs, how about your own > filesystem? I will note that this never modifies the debugfs code. But it does circumvent it. That is, all this code lives in kernel/trace/trace.c. I don't modify any of the debugfs code. I just replace the debugfs dentry->d_inode->i_op with my own ops. I can create my own fs, but that just seems to be overkill. The only difference is that I need mkdir and rmdir for this one instance. That said, perhaps it wouldn't be too hard to create a ftracefs. Where should it go? fs/ftrace or perhaps kernel/trace/fs ? I notice that I only use: debugfs_create_file() debugfs_remove(); debugfs_create_dir(); debugfs_remove_recursive(); debugfs_initialized() so maybe it wouldn't be such a far fetch thing to implement. But then would I be able to still mount it in /debug/tracing ? As this is where everything currently uses it? But then we need to teach admins to add it there, or someplace else. /sys/kernel/ftrace? Tools like trace-cmd and perf already expect it to be in the debugfs tracing directory, and will automate mounting it to /sys/kernel/debug/ if not found. This may break userspace if I make another fs. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
