On Wed, 2026-07-29 at 00:16 +0000, Arthur Kiyanovski wrote: > > > if (ptp->info->gettimexattrs64) > > err = ptp->info->gettimexattrs64(ptp->info, &ts, &sts, &att); > > else if (ptp->info->gettimex64) > > err = ptp->info->gettimex64(ptp->info, &ts, &sts); > > else > > return -EOPNOTSUPP; > > > > A userspace that respects the capability bits would refuse to call the > > new ioctl on drivers that would in fact serve it via the fallback. Is > > the fallback intended, and if so, should the caps advertise it? The > > commit message does not describe this behavior. > > > > The fallback is intentional. I'll widen the caps in v6 so they advertise it > (gettimexattrs64 || gettimex64, getcrosststampattrs || getcrosststamp) and > document the behavior in the commit message. Thanks.
FWIW I kind of hate this pattern. I understand it's how PTP does things, so I'm not suggesting you change it now, but these are all *kernel* functions not userspace API, so why not just add the new argument to the existing function rather than adding a new function? In the linux-phc rework it basically all collapses down to *one* function that's needed to read a clock, with a bunch of optional arguments. (Which I guess means that in a very short period of time, I'll stop caring how awful it is in the PTP code...)
smime.p7s
Description: S/MIME cryptographic signature
