----- Forwarded message from Matt Zimmerman <[EMAIL PROTECTED]> -----
Date: Mon, 22 Apr 2002 11:21:18 -0400 From: Matt Zimmerman <[EMAIL PROTECTED]> To: Ian Freislich <[EMAIL PROTECTED]> Subject: Re: architecture independant RRD files On Mon, Apr 22, 2002 at 05:00:43PM +0200, Ian Freislich wrote: > A while ago you expressed some interest in creating architecture > independant RRD files. We run a mixture of i386 and Sparc and are > starting to become interested making this become a reality some time in > the near future. Tobi recomended that I speak to you to get some ideas on > how the best way to implement this, or if you had some code that does > something like this lurking around. > > Over the next few weeks, I'll have a small bit of time to figure out the > internals of RRDTool and perhaps do the work if I can be pointed in the > right direction philosophically and religiously - I don't want to make a > bad design descision. This discussion really should be on rrd-developers so that it is archived for others who are interested, and so that others can critique our ideas. Feel free to quote any or all of this message publicly. If you give the same permission, I'll resend this message to the list. I have been caught up in other projects, and have not been able to put any real time into implementing this feature. The fact that there exists an easy (though inconvenient) workaround makes it that much harder to devote time to it. What Tobi and I discussed was using xdr to provide a portable representation for floating-point values. The necessary interfaces are all part of glibc (man 3 xdr), though probably not everywhere else, so this will need to be an optional feature in order to allow rrdtool to continue to build on platforms that don't have xdr available. There is a magic number in the RRD which is checked to ensure that the floating-point representation used in the database is consistent with the host's native format (which is what causes the architecture check to fail). For an xdr-based format, we would encode the same magic number in xdr format and store that in the same slot in the header, so that other rrdtools supporting xdr could recognize it. It was also generally agreed that development for this should be on the 1.1.x branch. One concern that I have (I'm not familiar with the actual implementation of xdr) is that the size of an xdr-encoded value may not be the same size as the native representation. This means that the offsets in the RRD header would be different, so it would be inconvenient to support both native and XDR format in the same executable. This probably would not be an issue if a simplistic native->xdr converter were provided. It should just be a matter of adding an xdr conversion layer anywhere floating point data is read from or written to the file. This should affect the pdp, cdp and rra areas (though I haven't done an exhaustive check). -- - mdz ----- End forwarded message ----- -- - mdz -- Unsubscribe mailto:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://www.ee.ethz.ch/~slist/rrd-developers WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
