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