This makes perfect sense. This is portable too. For stuff that uses
greater precision (like TCP timestamps) they can be printed in the precision
that is most sensible for the implementation.
>
> Always having microsecond resolution is a bad idea. Because something is
> bound to come along that wants nanoseconds. So if you just basically say
> that any fractional amount should always be printed out as a floating
> point number, then you're fine.
>
> (Obviously you don't actually want to use fp math inside the kernel:
> printing out numbers in a fp format does _not_ imply using actual fp
> arithmetic. The code does it all with integer arithmetic right now).
No problem, I'm aware of Integer vs Floating point issues.
Not to keep beating a dead horse, but I'd like to solidify the standing
of endianess in numbers in /proc. I've already proposed creating generic
formatting routines for /proc info, and I think that the output should be
big endian for Hex, Binary, and Decimal, as it's significantly easier
to read and parse. This also applies for the input data format of the
generic formatting routines; I'd like to ensure that all data passed
into them is big endian so that the interface is consistent.
>
> Linus
>
--Perry
PS: My boss let us off early today, so I'll be able to get a jump on this :)
-- Perry Harrington Linux rules all OSes. APSoft () email: perry@apsoft.com Think Blue. /\- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/