On Tue, Apr 2, 2024 at 2:25 AM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > > On Mon, Apr 01 2024 at 22:42, Mahesh Bandewar (महेश बंडेवार) wrote: > > On Mon, Apr 1, 2024 at 1:46 PM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > >> So if there is a backwards compability issue with PTP_SYS_OFFSET2, then > >> you need to introduce PTP_SYS_OFFSET3. The PTP_SYS_*2 variants were > >> introduced to avoid backwards compatibility issues as well, but > >> unfortunately that did not address the reserved fields problem for > >> PTP_SYS_OFFSET2. PTP_SYS_OFFSET_EXTENDED2 should just work, but maybe > >> the PTP maintainers want a full extension to '3'. Either way is fine. > >> > > https://patchwork.kernel.org/project/netdevbpf/patch/20240104212436.3276057-1-maheshb@xxxxxxxxxx/ > > > > This was my attempt to solve a similar issue with the new ioctl op to > > avoid backward compatibility issues. Instead of flags I used the > > clockid_t in a similar fashion. > > Works as well. I'm not seing the point for CLOCK_MONOTONIC and the > change logs are not really telling anything about the problem being > solved.... > https://lore.kernel.org/lkml/20240104212431.3275688-1-maheshb@xxxxxxxxxx/T/#:~:text=*%20[PATCHv3%20net%2Dnext%200/3]%20add%20ptp_gettimex64any()%20API,21:24%20Mahesh%20Bandewar%200%20siblings%2C%200%20replies; This is the cover letter where I tried to explain the need for this. Granted, my current use case is for CLOCK_MONOTONIC_RAW but just because I don't have a use case doesn't mean someone else may not have it and hence added it. In either way it's just a matter of adding/removing another flag/clock-id. Thanks, --mahesh.. > Thanks, > > tglx