This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: test case bin3 failed in my x86_64 box


Frank Ch. Eigler wrote:

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



Sorry to join the party late, but i think tapsets should not implement endianness and i also think tapsets should stay away from binary printf as much as possible. In other words in my view tapsets should be as much platform independent as possible unless the tapset is platform specific.


Coming to endianness for a script i think we should support script wide option at compile time as i am not finding need for one statement in a script to output big endian and other statement to output little endian. I think this is not a problem for us to supporting pre-compiled modules in the future, as we don't expect them to be portable across platforms.

Hien's question able to analyze the data produced on one platform using tools on another i think it is a good feature but not necessarily a high priority in my view.

bye,
Vara Prasad


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]