>>It might be better to create a program to convert RRD files in one go >> (we can already do an XML export/import of course) though this too >>could be more trouble than it is worth.
Could be useful, especially for large files. > I believe so, too. Reads/writes are done usually tens of thousands in > a monitoring period (with load peaks) while changing the architecture > of the machine is done once a several years... Not necessarily. Some people are using a light weight version of rrdtool update to gather their data, and use another machine to generate the graphs. Right now that other machine need to use the same byte order, alignement, and what more. I'm not saying that such a specific case justifies architecture indepentend files (nor am I saying that it does not, by the way). Maybe the way to go is this: If needed: change/expand the magic number so that it can be used to detect all different kinds of architecture Have fixed sized integers and other numbers parts that write (e.g. rrdtool update) work in their own architecture parts that only read (e.g. rrdtool graph) contain code to read different architecture This results (or so I think now) in: fast what needs to be fast, flexible what needs to be flexible. Variable functions (is that the name I'm looking for?) could be used. Interprete the magic number, and based on the outcome let function rrd_read_long point to rrd_read_long_LE_x86() or rrd_read_long_BE_64() or ... just thinking out loud, cheers, alex _______________________________________________ rrd-users mailing list rrd-users@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users