Re: test case bin3 failed in my x86_64 box

[fche at redhat dot com (Frank Ch. Eigler)]

hunt wrote:

> > More than that: set_endian being an ordinary function call, one can
> > imagine separately authored tapset probes to fight over it.
>
> We cannot and should not attempt to prevent programmers from writing
> nonsense. All we can do is make sure it is harmless nonsense.

The problem in this scenario is that two independent programmers may
set conflicting "default" endianness in their respective tapsets, and
a script may pull both in.  Who in this picture is writing "nonsense"?
How should they have known?

> [...]  I am guessing from "whims of script code" you expect the user
> will have a better idea of what endianess to write binary data
> in. Why?

I was guessing one usage scenario: that a user wants to feed in a
binary trace stream to an analysis tool of her choice.  She knows what
format the tool expects, and thus informs systemtap of its required
endianness.

But this scenario doesn't make much sense.  Unless systemtap prints
out metadata, a generic trace tool will have enough problem just
parsing the data into records, never mind decoding the endianness.

> I expect binary data to be used when the script must output an
> exactly formatted binary file, and the endianess is not something
> that the user should be able to change.

If so, and if a particular forced endianness is required, why not have
the tapset script use the explicit-endian formatting directives?  Just
to save typing on those "-"/"+" sign?  Is that worth the risk of
interference from unforseen probes that have the opposite idea?

Anyway, this subject could use more background: what did you guys have
in mind with respect to the overall end-to-end flow of data?  What
program is to read this data?  How?  Why expect it to have problems
with (say) native endianness?


- FChE