[rrd-developers] [mdz at debian.org: Re: architecture independant RRD files]

[Matt Zimmerman]

----- Forwarded message from Matt Zimmerman <mdz at debian.org> -----

Date: Mon, 22 Apr 2002 11:21:18 -0400
From: Matt Zimmerman <mdz at debian.org>
To: Ian Freislich <ianf at za.uu.net>
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:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-developers
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi