Message-ID: <CAM0EoMmYMt5rR56LRnfQaH-x74A9CNdhOh+jwohREFa0NzbKUw@mail.gmail.com>
Date:   Sat, 25 Feb 2023 12:21:41 -0500
From:   Jamal Hadi Salim <jhs@...atatu.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Stephen Hemminger <stephen@...workplumber.org>, dsahern@...il.com,
        Johannes Berg <johannes@...solutions.net>,
        netdev@...r.kernel.org
Subject: Re: [PATCH iproute2] genl: print caps for all families

On Fri, Feb 24, 2023 at 7:56 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Fri, 24 Feb 2023 14:33:27 -0800 Stephen Hemminger wrote:
> > > I'm biased but at this point the time is probably better spent trying
> > > to filling the gaps in ynl than add JSON to a CLI tool nobody knows
> > > about... too harsh? :
> >
> > So I can drop it (insert sarcasm here)
>
> It may be useful to experts as a for-human-consumption CLI.
>
> JSON to me implies use in scripts or higher level code, I can't
> think of a reason why scripts would poke into genl internals.
> E.g. if a script wants something from devlink it will call devlink,
> and the devlink tool internally may interrogate genl internals.
>

genl was/is mostly useful for debugging. Ive used it on/off to check
on things but on its own not much use.

> IOW we're tapping into a layer in the middle of the tech stack,
> while user wants JSON out of the end of the stack.
>

Only reason to make it json capable is for consistency with the rest
of iproute2 (given the effort to convert all prints to json). Main
value for json is providing a more formal, parseable output. Probably
not for genl, but generally for iproute2 utilities, example tc,
running tc -j | jq somethinghere | grep ..  is more predictable in
outcome than using text output piped to grep (which is what people
used to do before  -j); we extensively use it in tdc for example.

> [We can replace ynl with a iproute2 internal lib or libml to avoid bias]
> Now, what I'm saying is - for devlink - we don't have a easy to use
> library which a programmer can interact with to query the family info.
> Parsing thru the policy dumps is _hard_. So building a C library for
> this seems more fruitful than adding JSON to the CLI tool.
>
> IDK if I'm making sense.  I could well be wrong.

Not familiar with ynl, but if it is a library then I would suggest it
be part of iproute2 to avoid code replication etc. The LinuxWay(tm) is
CutnpasteThenEditAway - a lot of code in iproute2 is very templateable
so would benefit that way. Such code is also susceptible to human
error (see Pedros patches to fix broken usage of "index" parsing in tc
actions).

Re Devlink (or any other users): one of the original goals of generic
netlink was to seek the source of truth from the kernel via
introspection to discover properties of the different users, their
families, commands, etc and then formulate what will be acceptable to
send from user space. Some of that code unfortunately never went in
(mostly because it was an idea that I had but no users existed at the
time); Johannes I believe introduced policy discovery at some point
which may make it feasible now. The idea then is the CLI would query
the kernel for the properties, build enough details and then process
user requirements with the known constraints. Maybe that idea is still
too ambitious.

For sure having a centralized CLI that is widely adopted helps - a lot
of the code is very templa. It's a lot easier to evolve current tools
than to replace them even when the evolution is superficial. Folks
familiar with "ip" or "tc" (and already have the certification to
prove it) would be happier to stick with those interfaces than
creating a new one. If you are a developer and want to write your own
application then having well formed libraries (probably polyglot) is
very valuable; however, that doesnt contradict the need for
operational tooling such as provided by iproute2.

I worry I may have rambled without addressing the essence what you are asking;->

cheers,
jamal

Powered by blists - more mailing lists