On Fri, Nov 24, 2023 at 06:34:31PM +0100, Köry Maincent wrote: > Would it break things if both ioctls and netlink can get and set the > hwtstamps configuration? Uhm, obviously? It would break things if ioctl and netlink were _not_ freely interchangeable, and you couldn't see in a ioctl GET what got set through a netlink SET. > It is only configuration. Both happen under rtnl_lock it should be > alright. Yeah, but you always need to keep the API interchangeability in mind during the implementation. > The question is which hwtstamp provider will the original ioctls be able to > change? Maybe the default one (MAC with phy whitelist) and only this one. TL;DR: yeah. Remember one single rule and go from there: new development should not change established setups. So SIOCSHWSTAMPs should continue to behave "as before". This is also the exact reason why I asked for the phy whitelist. The introduction of CONFIG_NETWORK_PHY_TIMESTAMPING introduced exactly that: a breaking change in the mode in which deployed setups operate. > > But by all means, still hold a poll if you want to. I would vote for > > ethtool netlink, not because it's great, just because I don't have a > > better alternative to propose. > > If you agree on that choice, let's go. Jakub and your are the most proactive > reviewers in this patch series. Willem you are the timestamping maintainer do > you also agree on this? > If anyone have another proposition let them speak now, or forever remain > silent! ;) Hmm, proactive means doing stuff in anticipation of being requested to do it. I'd use the work "active" at most...
