On 05.07.24 17:02, David Woodhouse wrote: > On Fri, 2024-07-05 at 10:12 +0200, Peter Hilber wrote: >> On 03.07.24 12:40, David Woodhouse wrote: [...] >>> • Why is maxerror in picoseconds? It's the only use of that unit > > Between us we now have picoseconds, nanoseconds, (seconds >> 64) and > (seconds >> 64+n). > > The power-of-two fractions seem to make a lot of sense for the counter > period, because they mean we don't have to perform divisions. > > Does it makes sense to harmonise on (seconds >> 64) for all of the > fractional seconds? Again I don't have a strong opinion; I only want us > to have a *reason* for any differences that exist. > I don't have the expertise with fixed-point arithmetic to judge if this would become unwieldy. I selected ns for the virtio-rtc drafts so far because that didn't have any impact on the precision with the Linux kernel driver message-based use cases, but that would be different for SHM in my understanding. So I would tend to retain ns for convenience for messages (where it doesn't impact precision) but do not have any preference for SHM. >>> • Where do the clock_status values come from? Do they make sense? >>> • Are signed integers OK? (I think so!). >> >> Signed integers would need to be introduced to Virtio, which so far only >> uses explicitly unsigned types: u8, le16 etc. > > Perhaps. Although it would also be possible (if not ideal) to define > that e.g. the tai_offset field is a 16-bit "unsigned" integer according > to virtio, but to be interpreted as follows: > > If the number is <= 32767 then the TAI offset is that value, but if the > number is >= 32768 then the TAI offset is that value minus 65536. > > Perhaps not pretty, but there isn't a *fundamental* dependency on > virtio supporting signed integers as a primary type. > Agreed.
