Re: [PATCH 1/2] trace-cmd: Add validation for reading and writing trace.dat files

[Tzvetomir Stoyanov <tz.stoyanov@gmail.com>]

On Wed, Feb 17, 2021 at 8:27 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Wed, 17 Feb 2021 18:33:32 +0200
> Tzvetomir Stoyanov <tz.stoyanov@gmail.com> wrote:
> > >
> > > Why did you use bits, and not just a number?
> > >
>
> >
> > I use these flags to track what is in the file, not just a state. The
> > state is the most significant bit which is set,
> > but that way there is information for all passed states. I use the
> > same logic when reading the file, to verify if
> > all required information is in the file.
>
> Of course if this is done via states, entering one state assumes that all
> previous states have been entered (and thus must be set). For cases of
> FLYRECORD and LATENCY, those two would diverge in states (basically like
> branches in a tree), but still maintain that being in any given state,
> stores the information that all previous states have been hit.
>
> Or do you know of a situation where that is not the case?

This works for the current structure of trace.dat file, we can have
these assumptions
and use state instead of a bitmask. But in the future, if we decide to
add optional
sections in the file, or more complex branches - assumptions could not
be valid and
state should be changed to something more flexible.
As this is not part of any external API, I'm OK to change bitmask to
state. This easily
can be redesigned in the future, if needed.

>
> -- Steve



-- 
Tzvetomir (Ceco) Stoyanov
VMware Open Source Technology Center