Accounting changes

[Peter Jeremy]

On 2007-May-06 12:06:02 +0300, Diomidis Spinellis <dds at aueb.gr> wrote:
>Garance A Drosehn wrote:
>>Does this mean the new accounting record will be using the
>>native-hardware format for floating point numbers?  Does that mean
>>the records produced will be different for different hardware?
>
>My intention is to use the standard (IEEE 754-1985 / IEEE 854-1987 / IEC 
>60559) 32-bit float format.  This is the C "float" type on all the 
>architectures we support.  I could add a typedef clarifying this, but I 
>doubt we'll ever support an architecture (VAX?) where float is a 
>different format.

IEEE-754 etc define how to interpret a 32-bit object as a floating
point number.  AFAIK, it does not define how that object is laid
out in memory so that a float written on SPARC (big-endian) will
be different to that written on an i386 (little-endian).

Accounting records do not need all the features that a general FP
format needs:
- No need to support negative numbers
- It is easy to define comp_t so there are no negative exponents
- No need to support denormals
- No need to support NaN
- Supporting infinity is optional.

This means that it's possible to define a format that is relatively
easy to manipulate or convert into a "standard" C FP format.

>>I also wonder about using a time_t for ac_btime (starting time).
>>Now that we're running freebsd on very fast, multi-processor systems,
>>we might care whether "<this>-command" executed before "<that>-command",
>>and we might wish to have better resolution for the start-time of a
>>given command.

On a multi-processor machine, both commands may have begun at the same
time (measured to whatever precision you want).  There are occasional
discussions regarding file timestamps (lack of precision can confuse
make) - which is a related issue.  The decision as to whether make
ac_time a time_t or (eg) struct timespec is not obvious: There is a
definite space disadvantage to increasing ac_time precision (though
there's only one instance per accounting record so the problem isn't
as serious as comp_t).  OTOH, I can see theoretical reasons for
wanting to know which command came first.

This is probably a question that needs wider discussion:  Has there
been any request for greater precision within the FreeBSD user
community?

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20070506/aa46de9e/attachment.pgp