Re: [PATCH v2] libtracefs: Add new API for open trace marker file

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 8 Apr 2021 16:21:52 +0300
Tzvetomir Stoyanov <tz.stoyanov@gmail.com> 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