netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Jiri Pirko <jiri@resnulli.us>
Cc: netdev@vger.kernel.org, pabeni@redhat.com, davem@davemloft.net,
	edumazet@google.com, jacob.e.keller@intel.com,
	swarupkotikalapudi@gmail.com, donald.hunter@gmail.com,
	sdf@google.com, lorenzo@kernel.org,
	alessandromarcolini99@gmail.com
Subject: Re: [patch net-next 03/13] tools: ynl: allow user to pass enum string instead of scalar value
Date: Tue, 20 Feb 2024 17:59:18 -0800	[thread overview]
Message-ID: <20240220175918.73026870@kernel.org> (raw)
In-Reply-To: <ZdRUfZMRvjMlDqtX@nanopsycho>

On Tue, 20 Feb 2024 08:27:57 +0100 Jiri Pirko wrote:
> >If the user mistakenly passes a single value for a flag, rather than 
> >a set, this is going to generate a hard to understand error.
> >How about we check isinstance(, str) and handle that directly,
> >whether a flag or not.  
> 
> Yeah, I was thinking about that as well. But as the flag output is
> always list, here we expect also always list. I can either do what you
> suggest of Errout with some sane message in case of the variable is not
> a list. I didn't find ynl to be particularly forgiving in case of input
> and error messages, that is why I didn't bother here.

It's not the same thing, but (without looking at the code IIRC)
for multi-attr we do accept both a list and direct value.
Here we don't have to be lenient in what we accept.
Clear error message would be good enough.

Some of the sharp edges in Python YNL are because I very much
anticipated the pyroute2 maintainer to do a proper implementation, 
and this tool was just a very crude PoC :D

  reply	other threads:[~2024-02-21  1:59 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-19 17:25 [patch net-next 00/13] netlink: specs: devlink: add the rest of missing attribute definitions Jiri Pirko
2024-02-19 17:25 ` [patch net-next 01/13] tools: ynl: allow user to specify flag attr with bool values Jiri Pirko
2024-02-19 20:42   ` Jakub Kicinski
2024-02-20  7:24     ` Jiri Pirko
2024-02-19 17:25 ` [patch net-next 02/13] tools: ynl: process all scalar types encoding in single elif statement Jiri Pirko
2024-02-19 17:25 ` [patch net-next 03/13] tools: ynl: allow user to pass enum string instead of scalar value Jiri Pirko
2024-02-19 20:49   ` Jakub Kicinski
2024-02-20  7:25     ` Jiri Pirko
2024-02-21  1:55       ` Jakub Kicinski
2024-02-21 14:31         ` Jiri Pirko
2024-02-19 20:51   ` Jakub Kicinski
2024-02-20  7:27     ` Jiri Pirko
2024-02-21  1:59       ` Jakub Kicinski [this message]
2024-02-21 11:40         ` Donald Hunter
2024-02-19 17:25 ` [patch net-next 04/13] netlink: specs: allow sub-messages in genetlink-legacy Jiri Pirko
2024-02-19 20:51   ` Jakub Kicinski
2024-02-20  7:28     ` Jiri Pirko
2024-02-19 17:25 ` [patch net-next 05/13] tools: ynl: allow attr in a subset to be of a different type Jiri Pirko
2024-02-19 17:25 ` [patch net-next 06/13] tools: ynl: introduce attribute-replace for sub-message Jiri Pirko
2024-02-19 22:52   ` Jakub Kicinski
2024-02-20  7:31     ` Jiri Pirko
2024-02-21  2:10       ` Jakub Kicinski
2024-02-21 12:48         ` Jiri Pirko
2024-02-21 18:45           ` Jakub Kicinski
2024-02-22 13:20             ` Jiri Pirko
2024-02-19 17:25 ` [patch net-next 07/13] tools: ynl: add support for list in nested attribute Jiri Pirko
2024-02-19 17:25 ` [patch net-next 08/13] netlink: specs: devlink: add enum for param-type attribute values Jiri Pirko
2024-02-19 17:25 ` [patch net-next 09/13] netlink: specs: devlink: add missing param attribute definitions Jiri Pirko
2024-02-19 17:26 ` [patch net-next 10/13] netlink: specs: devlink: treat dl-fmsg attribute as list Jiri Pirko
2024-02-19 17:26   ` [patch net-next 11/13] netlink: specs: devlink: add enum for fmsg-obj-value-type attribute values Jiri Pirko
2024-02-19 17:26   ` [patch net-next 12/13] netlink: specs: devlink: add missing fmsg-obj-value-data attribute definitions Jiri Pirko
2024-02-19 17:26   ` [patch net-next 13/13] netlink: specs: devlink: add missing nested devlink definitions Jiri Pirko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240220175918.73026870@kernel.org \
    --to=kuba@kernel.org \
    --cc=alessandromarcolini99@gmail.com \
    --cc=davem@davemloft.net \
    --cc=donald.hunter@gmail.com \
    --cc=edumazet@google.com \
    --cc=jacob.e.keller@intel.com \
    --cc=jiri@resnulli.us \
    --cc=lorenzo@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sdf@google.com \
    --cc=swarupkotikalapudi@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).