netdev - Re: [PATCH net-next v3 0/3] ptp: Support for multiple filtered timestamp event queue readers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87y1go4ki0.fsf@intel.com>
Date: Fri, 29 Sep 2023 16:39:35 -0700
From: Vinicius Costa Gomes <vinicius.gomes@...el.com>
To: Xabier Marquiegui <reibax@...il.com>, netdev@...r.kernel.org
Cc: richardcochran@...il.com, horms@...nel.org,
 chrony-dev@...ony.tuxfamily.org, mlichvar@...hat.com, reibax@...il.com,
 ntp-lists@...tcorallo.com, alex.maftei@....com, davem@...emloft.net,
 rrameshbabu@...dia.com, shuah@...nel.org
Subject: Re: [PATCH net-next v3 0/3] ptp: Support for multiple filtered
 timestamp event queue readers

Xabier Marquiegui <reibax@...il.com> writes:

> On systems with multiple timestamp event channels, there can be scenarios where
> multiple userspace readers want to access the timestamping data for various
> purposes.
>
> One such example is wanting to use a pps out for time synchronization, and
> wanting to timestamp external events with the synchronized time base 
> simultaneously.
>
> Timestmp event consumers on the other hand, are often interested in a subset of
> the available timestamp channels. linuxptp ts2phc, for example, is not happy if
> more than one timestamping channel is active on the device it is reading from.
>
> This patch-set introduces linked lists to support multiple timestamp event queue
> consumers, and timestamp event channel filters through IOCTLs.
>
> Signed-off-by: Xabier Marquiegui <reibax@...il.com>
> Suggested-by: Richard Cochran <richardcochran@...il.com>

On the series organization side, my suggestion about the order of things:

1. Any preparation work;
2. Introduce the new UAPI: the ioctls (this needs to be front and center, as it has
   to be maintained for a long time);
3. Changes to the "core" (posix_clock and friends);
4. "glueing" everything together in the driver;
5. Tests;

(it is possible that that the "preparation" can be moved to the
"glueing" part)


Cheers,
-- 
Vinicius