On Mon, Apr 1, 2024 at 1:46 PM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > > Sagi! > > On Thu, Mar 28 2024 at 17:40, Sagi Maimon wrote: > > On Sat, Mar 23, 2024 at 2:38 AM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > >> On top this needs an analyis whether any of the gettimex64() > >> implementations does something special instead of invoking the > >> ptp_read_system_prets() and ptp_read_system_postts() helpers as close as > >> possible to the PCH readout, but that's not rocket science either. It's > >> just 21 callbacks to look at. > >> > > I like your suggestion, thanks! > > it is what our user space needs from the kernel and with minimum kernel changes. > > I will write it, test it and upload it with your permission (it is you > > idea after all). > > You don't need permission. I made a suggestion and when you are doing the > work I'm not in a position to veto posting it. We have an explicit tag > for that 'Suggested-by:', which only says that someone suggested it to > you, but then you went and implemented it, made sure it works etc. > > >> It might also require a new set of variant '3' IOTCLS to make that flag > >> field work, but that's not going to make the change more complex and > >> it's an exercise left to the experts of that IOCTL interface. > >> > > I think that I understand your meaning. > > There is a backward compatibility problem here. > > > > Existing user space application using PTP_SYS_OFFSET_EXTENDED ioctl > > won't have any problems because of the "extoff->rsv[0] || > > extoff->rsv[1] || extoff->rsv[2]" test, but what about all old user > > space applications using: PTP_SYS_OFFSET ? > > 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. Thanks, > Thanks, > > tglx > >
