Re: [PATCH v2 1/2] libtraceeval: Remove need to use TRACEEVAL_TYPE_NONE in keys and vals

[Steven Rostedt <rostedt@goodmis.org>]

On Tue, 3 Oct 2023 09:39:20 -0600
Ross Zwisler <zwisler@google.com> wrote:

> IMO trying to support both types of inputs (ending with TRACEEVAL_TYPE_NONE
> and just relying on the element count) is probably bad long term because one
> or the other will break and we may not notice, and we'll have to make sure we
> keep up both.

I plan on really only supporting the one type (defined size), the
TRACEEVAL_TYPE_NONE will not be shown in the man pages. The reason I want
to keep them is mostly for debugging (can add this to test issues and what not).

So yeah, I agree we only want to support one, and we are going to do that,
but the other will still be there "hidden" from the users ;-)

> 
> As we don't really have users yet (do we?) can we just move fully over to the
> count way and give on the other?
> 
> In either case, we probably need to still update the comments above
> type_alloc(), traceeval_init_data_size() and traceeval_insert_size() which
> talk about how we rely on TRACEEVAL_TYPE_NONE to terminate our element lists.

Will do that in another patch. But right now I'm working on the man pages,
and that's really where I expect people to get their information on how to
use the library.

> 
> What we have here though is correct:
> Reviewed-by: Ross Zwisler <zwisler@google.com>

Thanks,

-- Steve