On Thu, Mar 08, 2018 at 07:18:04PM +0000, Michael Brown wrote:
> Can you give me some idea of what names will be acceptable? I was trying to
> fit within the current naming scheme as closely as possible, but I'm very
> happy to redo it with whatever names you prefer.
Let me think about this. Part of the problem is the hwts.sw field,
which is an ugly hack to being with. That probably should be changed.
> One idea is to extend struct scm_timestamping to append a fractional
> nanosecond field for the hardware timestamp only. This would produce a
> layout that is backwards compatible with older userspace, which would simply
> ignore the fractional part (assuming that it does a minimum-length rather
> than exact-length check on cmsg_len).
>
> Does this sound sensible?
For the kernel, I (and others) would like to get away from the clunky
timespec altogether. Dividing a time value into two fields might have
made sense 30 years ago when operations on eight byte words were
expensive, but today it makes no sense. It only causes pointless
extra computation, first in user space and again the kernel,
converting to and from the timespec.
How about this?
SOF_TIMESTAMPING_HIGH_RES requests time stamps in a new format:
struct {
uint64_t nanoseconds;
uint32_t fractional_nanoseconds;
uint32_t reserved;
};
Would that be enough resolution for you?
Also, will you be able to mainline your driver? It helps new kernel
API acceptance when there is an actual, realistic use case and users.
Thanks,
Richard
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
