Having headers definitely has benefit to oprofile. The lack of header
will cause problems in the future. Currently, all the platforms are ia32
and the expectation is the analysis is done on the same machine that the
data was collected on. The embedded and carrier grade linux platforms
can benefit from the data that oprofile collects. For these systems the
data has to be moved elsewhere for analysis. It is likely that there
will be differences between the native data formats used by the machine
to collect the data and the native data format used by machine to
analyze the data (e.g. powerpc big-endian embedded target and ia32
little-endian host for data analysis). The header in the data files
provides a means of catching those mismatch problems, rather than
silently doing the wrong thing or mysteriously dying much later in the
Raw binary files without any information about the layout or data format
are a problem. It makes it very hard to "do the right" when migrating
the data to another system. op_export and op_import commands are going
to be more error prone without the header information because the user
will have to specify the input file format and there will be no way to
check that is correct.
It would much much better to address this host/target problem with
headers now rather than have people complain about it a year from now
after someone ports OProfile to something that is not an ia32 processor.
Then we change the oprofile data format to support headers a year from
now. The overhead for the header is small and only occurs to check to
see that the file is in the appropriate format. The code that reads in
the data needs does not need to change.
Tools such as gprof have headers in their data format and already do
checks to avoid endian problems. This allows the gmon.out file to be
portable between machines:
John Levon wrote:
> On Sun, Oct 13, 2002 at 05:09:41PM -0400, graydon hoare wrote:
>>Perhaps. Your point about flexibility for future change in the native
>>format is the only one I'd worry about, with this patch. There is no
>>performance impact at all
> Fine. Performance obviously isn't an issue with this patch.
>>, nor "99% path" complication
> Well, there is. You're writing out a complicated header that nobody
> needs in 99% of cases.
>>And I do feel that there is an advantage to this approach: a sample file
>>we retrieve from a user is in *exactly* the form it was written to disk
>>by the daemon, not modified by op_export.
> You're correct - this is an advantage to your approach. However, on
> balance, I don't feel this outweighs the ugliness of this header stuff.
> I really think that if you need this, it should be in op_export only -
> that code will bootstrap its own knowledge of the native layout, and
> write out all the ABI goop you need (or some other format). This
> localises the stuff so it's only needed for the very rare cases.
> And yes, you'll need an op_import too, but you are going to need that
> *anyway* - else how could you run oprofpp or whatever ? It makes far
> better sense to localise the inherent ugliness of reading non-native
> structures into a simple translation tool, than include the stuff in
> basic libdb.
> The only problem that could require the "exact form" of the file would
> be bugs in ABI writing OR reading. This remains true whether it's in
> external op_import/export tools, or in the main libdb code. So what
> changes ?
> In summary: I'd definitely be OK with op_export/import in CVS, but I
> don't think we want this in its present form.