On Thu, Jan 11, 2024 at 9:31 AM Richard Cochran <richardcochran@xxxxxxxxx> wrote: > > On Tue, Jan 02, 2024 at 12:29:59PM +0100, Arnd Bergmann wrote: > > > I think Andy's suggestion of exposing time offsets instead > > of absolute times would actually achieve that: If the > > interface is changed to return the offset against > > CLOCK_MONOTONIC, CLOCK_MONOTONIC_RAW or CLOCK_BOOTTIME > > (not sure what is best here), then the new syscall can use > > getcrosststamp() where supported for the best results or > > fall back to gettimex64() or gettime64() otherwise to > > provide a consistent user interface. > > Yes, it makes more sense to provide the offset, since that is what the > user needs in the end. > Make sense will be made on the next patch. > Can we change the name of the system call to "clock compare"? > > int clock_compare(clockid_t a, clockid_t b, > int64_t *offset, int64_t *error); > > returns: zero or error code, > offset = a - b > error = maximum error due to asymmetry > > If clocks a and b are both System-V clocks, then *error=0 and *offset > can be returned directly from the kernel's time keeping state. > > If getcrosststamp() is supported on a or b, then invoke it. > > otherwise do this: > > t1 = gettime(a) > t2 = gettime(b) > t3 - gettime(c) > > *offset = (t1 + t3)/2 - t2 > *error = (t3 - t1)/2 > > There is no need for repeated measurement, since user space can call > again when `error` is unacceptable. > Thanks for your notes, all of them will be done on the next patch (it will take some time due to work overload). The only question that I have is: why not implement it as an IOCTL? It makes more sense to me since it is close to another IOCTL, the "PTP_SYS_OFFSET" family. Does it make sense to you? > Thanks, > Richard > > >
