[RFC PATCH v2 0/3] Create common DPLL/clock configuration API

[Jakub Kicinski]

On Sat, 1 Oct 2022 07:47:24 +0200 Jiri Pirko wrote:
> >> Sure, but more hw does not mean you can't use sysfs. Take netdev as an
> >> example. The sysfs exposed for it is implemented net/core/net-sysfs.c
> >> and is exposed for all netdev instances, no matter what the
> >> driver/hardware is.  
> >
> >Wait, *you* are suggesting someone uses sysfs instead of netlink?
> >
> >Could you say more because I feel like that's kicking the absolute.  
> 
> I don't understand why that would be a problem. 

Why did you do devlink over netlink then?
The bus device is already there in sysfs.

> What I'm trying to say
> is, perhaps sysfs is a better API for this purpose. The API looks very
> neat and there is no probabilito of huge grow.

"this API is nice and small" said everyone about every new API ever,
APIs grow.

> Also, with sysfs, you
> don't need userspace app to do basic work with the api. In this case, I
> don't see why the app is needed.

Yes, with the YAML specs you don't need a per-family APP.
A generic app can support any family, just JSON in JSON out.
DPLL-nl will come with a YAML spec.

> These are 2 biggest arguments for sysfs in this case as I see it.

2 biggest arguments? Is "this API is small" one of the _biggest_
arguments you see? I don't think it's an argument at all. The OCP PTP
driver started small and now its not small. And the files don't even
follow sysfs rules. Trust me, we have some experience here :/

As I said to you in private I feel like there may be some political
games being played here, so I'd like to urge you to focus on real
issues.