[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240621182520.6f28d751@kmaincent-XPS-13-7390>
Date: Fri, 21 Jun 2024 18:25:20 +0200
From: Kory Maincent <kory.maincent@...tlin.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Florian Fainelli <florian.fainelli@...adcom.com>, Broadcom internal
kernel review list <bcm-kernel-feedback-list@...adcom.com>, Andrew Lunn
<andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>, Russell King
<linux@...linux.org.uk>, "David S. Miller" <davem@...emloft.net>, Eric
Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Richard
Cochran <richardcochran@...il.com>, Radu Pirea
<radu-nicolae.pirea@....nxp.com>, Jay Vosburgh <j.vosburgh@...il.com>, Andy
Gospodarek <andy@...yhouse.net>, Nicolas Ferre
<nicolas.ferre@...rochip.com>, Claudiu Beznea <claudiu.beznea@...on.dev>,
Willem de Bruijn <willemdebruijn.kernel@...il.com>, Jonathan Corbet
<corbet@....net>, Horatiu Vultur <horatiu.vultur@...rochip.com>,
UNGLinuxDriver@...rochip.com, Simon Horman <horms@...nel.org>, Vladimir
Oltean <vladimir.oltean@....com>, Thomas Petazzoni
<thomas.petazzoni@...tlin.com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org, Maxime Chevallier
<maxime.chevallier@...tlin.com>, Rahul Rameshbabu <rrameshbabu@...dia.com>
Subject: Re: [PATCH net-next v15 13/14] net: ethtool: tsinfo: Add support
for hwtstamp provider and get/set hwtstamp config
On Fri, 21 Jun 2024 08:56:00 -0700
Jakub Kicinski <kuba@...nel.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
https://bootlin.com
Powered by blists - more mailing lists