Re: [PATCH net-next v15 13/14] net: ethtool: tsinfo: Add support for hwtstamp provider and get/set hwtstamp config

Kory Maincent
2024-06-21T16:25:24Z

On Fri, 21 Jun 2024 08:56:00 -0700
Jakub Kicinski <kuba@kernel.org> wrote:

> On Fri, 21 Jun 2024 10:54:08 +0200 Kory Maincent wrote:
> [...]
> >
> > As I described it in the documentation it replaces SIOCGHWTSTAMP:
> > "Any process can read the actual configuration by requesting tsinfo netlink
> > socket ETHTOOL_MSG_TSINFO_GET with ETHTOOL_MSG_TSINFO_GHWTSTAMP netlink
> > attribute set.
> >
> > The legacy usage is to pass this structure to ioctl(SIOCGHWTSTAMP) in the
> > same way as the ioctl(SIOCSHWTSTAMP). However, this has not been
> > implemented in all drivers."
>
> I did see the words, just didn't get the meaning :> Couple of years
> from now hopefully newcomers won't even know ioctls exited, and
> therefore what they did. From the user perspective the gist AFAIU is
> that instead of *supported* we'll return what's currently *configured*.
>
> This feels a little bit too much like a muxed operation for me :(
> Can we create a separate commands for TSCONFIG_GET / _SET ?
> Granted it will be higher LOC, but hopefully cleaner ?
> Or we can add the configured as completely new attrs, but changing
> meaning of existing attrs based on a request flag.. 🙂‍↔️️

Ok so, you prefer to use a separate command to manage the hwtstamp
configurations. Keeping TSINFO for reading the hwtstamp capabilities.
I will bring back the TS_GET and TS_SET I have used from an older version of
this patch series but renaming it to TSCONFIG ;)

> [...]
> >
> > I am not a naming expert but "hwtstamp_provider" is the struct name I have
> > used to describe hwtstamp index + qualifier and the prefix of the netlink
> > nested attribute, so IMHO it fits well.
> > Have you another proposition to clarify what you would expect?
>
> Oh, I just meant that it's way to long. I know y'all youngsters use
> IDEs but I have it on good authority that there's still people in
> this community who use text editors they wrote themselves, and those
> lack auto-completion.. It's good to be more concise.

Don't have too high expectations of me, I am still using vim. Maybe I belong
also to the "old" people. ;)
Now that we can reach 100 characters by line we can write variable names as long
as we want! ^^
I will look for a shorter name then.

Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering