On Thu, 8 Apr 2021 16:21:52 +0300 Tzvetomir Stoyanov <tz.stoyanov@xxxxxxxxx> wrote: > I find "tracefs_print_" a little bit confusing, like printing > something on console. I think the name should stress that a user > string/data is written in the trace buffer. I would like to combine > string and binary APIs into one set, something like: How so? We use it in the kernel "trace_printk()" there's no confusion there. And to me, "user string written in the trace buffer" is exactly what I think when I see "tracefs_printf()". > > tracefs_user_trace_init(); /* open both trace_marker and > trace_marker_raw files, or have flags to specify what file to open, > string or data*/ > tracefs_user_trace_printf(); /* write to trace_marker */ > tracefs_user_trace_vprintf(); /* write to trace_marker */ > tracefs_user_trace_binary(); /* write to trace_marker_raw */ > tracefs_user_trace_init(); /* close both string and data fd, if open */ > I have no idea what "user_trace" is. What does that mean? There's no precedence for it. "tracefs_printf()" is short and to the point, and states exactly what you want. It does a printf() into the tracefs system. How is that confusing? We have fprintf() which does a printf into a file point. We have sprintf() which does an printf into a string. Thus, it makes sense to have "tracefs_printf()" which does a printf into the tracefs file system. Just like we have trace_seq_printf() which does a printf() into the trace_seq. "printf()" means string manipulation, and has nothing to do with consoles. I personally hate long function names, especially ones that I may use a lot of. Keeping with the other APIs trace_printf() is the only one that seems reasonable. -- Steve
|