On Thursday 24 September 2015 04:02:09 Drokin, Oleg wrote: > > The lustre tracefile has a timestamp defined as > > > > __u32 ph_sec; > > __u64 ph_usec; > > > > which seems completely backwards, as the microsecond portion of > > a time stamp will always fit into a __u32 value, while the second > > portion will overflow in 2038 or 2106 (in case of unsigned seconds). > > > > This rectifies the situation by swapping out the types to have > > 64-bit seconds like everything else. > > > > While this constitutes an ABI change, it seems to be reasonable > > for a debugging interface to change and is likely what was > > originally intended. > > This is going to wreak some havoc as the old tools would obviously > misrepresent this, but the new tools also cannot assume blindly > this change is in place, since people tend to stick to old > lustre modules for a long time in production for various reasons, > while the tools might get upgraded. > So I wonder if we should include some sort of a hint somewhere that > the lctl could read and see which format it's going to convert from. > Either that or we'd need to play with some heuristic in the tools > to observe where the leading zeros are (in little ending) in one > and the other case (if the year is not quite 2038 yet) and > make a decision based on that. Ok, I see. If you can prove that the user space tools interpret this value as a unsigned 32-bit number, that would work until 2106 and we could document it as a restriction that way. Another option would be to change the code storing the times there to do: header->ph_sec = (u32)ts.tv_sec; header->ph_usec = (ts.tv_sec & 0xffffffff00000000ull) | (ts.tv_nsec / NSEC_PER_USEC); and do the reverse on the user space side. This would be both endian- safe and backwards compatible, although rather ugly. Arnd _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
