From: Petr Machata <me@pmachata.org>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org, dsahern@gmail.com,
john.fastabend@gmail.com, jiri@nvidia.com, idosch@nvidia.com
Subject: Re: [PATCH iproute2-next 15/15] dcb: Add a subtool for the DCB ETS object
Date: Thu, 22 Oct 2020 01:48:58 +0200 [thread overview]
Message-ID: <873627jg2d.fsf@nvidia.com> (raw)
In-Reply-To: <20201021112838.3026a648@hermes.local>
Stephen Hemminger <stephen@networkplumber.org> writes:
> On Tue, 20 Oct 2020 22:43:37 +0200
> Petr Machata <me@pmachata.org> wrote:
>
>> Jakub Kicinski <kuba@kernel.org> writes:
>>
>> > On Tue, 20 Oct 2020 02:58:23 +0200 Petr Machata wrote:
>> >> +static void dcb_ets_print_cbs(FILE *fp, const struct ieee_ets *ets)
>> >> +{
>> >> + print_string(PRINT_ANY, "cbs", "cbs %s ", ets->cbs ? "on" : "off");
>> >> +}
>> >
>> > I'd personally lean in the direction ethtool is taking and try to limit
>> > string values in json output as much as possible. This would be a good
>> > fit for bool.
>>
>> Yep, makes sense. The value is not user-toggleable, so the on / off
>> there is just arbitrary.
>>
>> I'll consider it for "willing" as well. That one is user-toggleable, and
>> the "on" / "off" makes sense for consistency with the command line. But
>> that doesn't mean it can't be a boolean in JSON.
>
> There are three ways of representing a boolean. You chose the worst.
> Option 1: is to use a json null value to indicate presence.
> this works well for a flag.
> Option 2: is to use json bool.
> this looks awkward in non-json output
> Option 3: is to use a string
> but this makes the string output something harder to consume
> in json.
What seems to be used commonly for these on/off toggles is the following
pattern:
print_string(PRINT_FP, NULL, "willing %s ", ets->willing ? "on" : "off");
print_bool(PRINT_JSON, "willing", NULL, true);
That way the JSON output is easy to query and the FP output is obvious
and compatible with the command line. Does that work for you?
next prev parent reply other threads:[~2020-10-21 23:49 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-20 0:58 [PATCH iproute2-next 00/15] Add a tool for configuration of DCB Petr Machata
2020-10-20 0:58 ` [PATCH iproute2-next 01/15] Unify batch processing across tools Petr Machata
2020-10-20 0:58 ` [PATCH iproute2-next 02/15] lib: Add parse_one_of(), parse_on_off() Petr Machata
2020-10-20 0:58 ` [PATCH iproute2-next 03/15] bridge: link: Port over to parse_on_off() Petr Machata
2020-10-20 0:58 ` [PATCH iproute2-next 04/15] lib: Add parse_flag_on_off(), set_flag() Petr Machata
2020-10-20 0:58 ` [PATCH iproute2-next 05/15] ip: iplink: Convert to use parse_on_off(), parse_flag_on_off() Petr Machata
2020-10-20 0:58 ` [PATCH iproute2-next 06/15] ip: iplink_vlan: Port over to parse_flag_on_off() Petr Machata
2020-10-20 0:58 ` [PATCH iproute2-next 07/15] ip: iplink_bridge_slave: Port over to parse_on_off() Petr Machata
2020-10-20 0:58 ` [PATCH iproute2-next 08/15] lib: Extract from devlink/mnlg a helper, mnlu_socket_open() Petr Machata
2020-10-20 0:58 ` [PATCH iproute2-next 09/15] lib: Extract from devlink/mnlg a helper, mnlu_msg_prepare() Petr Machata
2020-10-20 0:58 ` [PATCH iproute2-next 10/15] lib: Extract from devlink/mnlg a helper, mnlu_socket_recv_run() Petr Machata
2020-10-20 0:58 ` [PATCH iproute2-next 11/15] lib: Extract from iplink_vlan a helper to parse key:value arrays Petr Machata
2020-10-20 11:33 ` Roman Mashak
2020-10-20 20:44 ` Petr Machata
2020-10-20 0:58 ` [PATCH iproute2-next 12/15] lib: parse_mapping: Update argc, argv on error Petr Machata
2020-10-20 0:58 ` [PATCH iproute2-next 13/15] lib: parse_mapping: Recognize a keyword "all" Petr Machata
2020-10-20 0:58 ` [PATCH iproute2-next 14/15] Add skeleton of a new tool, dcb Petr Machata
2020-10-20 0:58 ` [PATCH iproute2-next 15/15] dcb: Add a subtool for the DCB ETS object Petr Machata
2020-10-20 18:41 ` Jakub Kicinski
2020-10-20 20:43 ` Petr Machata
2020-10-21 18:28 ` Stephen Hemminger
2020-10-21 23:48 ` Petr Machata [this message]
2020-10-22 0:11 ` Stephen Hemminger
2020-10-22 7:16 ` Petr Machata
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=873627jg2d.fsf@nvidia.com \
--to=me@pmachata.org \
--cc=dsahern@gmail.com \
--cc=idosch@nvidia.com \
--cc=jiri@nvidia.com \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
/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).