On Fri, 2024-07-05 at 10:12 +0200, Peter Hilber wrote: > On 03.07.24 12:40, David Woodhouse wrote: > > [...] > > > > > > > This is what I currently have for 'struct vmclock_abi' that I'd like to > > persuade you to adopt. I need to tweak it some more, for at least the > > following reasons, as well as any more you can see: > > > > • size isn't big enough for 64KiB pages > > • Should be explicitly little-endian > > • Does it need esterror as well as maxerror? > > I have no opinion about this. I can drop esterror if unwanted. I also don't care. I'm just observing the inconsistency. > > • 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. > > • 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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
