[RFC PATCH v2] ptp: Add vDSO-style vmclock support
David Woodhouse
dwmw2 at infradead.org
Fri Jul 5 08:02:46 PDT 2024
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5965 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20240705/5d8e5e1f/attachment.p7s>
More information about the linux-arm-kernel
mailing list