On Mon, 15 Jul 2019 17:24:22 -0700, Stephen Hemminger wrote:
> On Mon, 15 Jul 2019 17:15:15 -0700
> Jakub Kicinski <jakub.kicin...@netronome.com> wrote:
> > On Mon, 15 Jul 2019 16:37:43 -0700, Stephen Hemminger wrote:
> > > On Mon, 15 Jul 2019 15:51:41 -0700
> > > Vedang Patel <vedang.pa...@intel.com> wrote:
> > > > @@ -442,6 +458,11 @@ static int taprio_print_opt(struct qdisc_util *qu,
> > > > FILE *f, struct rtattr *opt)
> > > >
> > > > print_string(PRINT_ANY, "clockid", "clockid %s",
> > > > get_clock_name(clockid));
> > > >
> > > > + if (tb[TCA_TAPRIO_ATTR_FLAGS]) {
> > > > + taprio_flags =
> > > > rta_getattr_u32(tb[TCA_TAPRIO_ATTR_FLAGS]);
> > > > + print_uint(PRINT_ANY, "flags", " flags %x",
> > > > taprio_flags);
> > > > + }
> > >[...]
> > > 3. Use the print_0xhex() instead of print_uint() for hex values. The
> > > difference
> > > is that in the JSON output, print_uint would be decimal but the
> > > print_0xhex
> > > is always hex. And use "flags %#x" so that it is clear you are
> > > printing flags in hex.
> >
> > In my humble personal experience scripting tests using iproute2 and
> > bpftool with Python I found printing the "hex string" instead of just
> > outputing the integer value counter productive :( Even tho it looks
> > better to the eye, JSON is primarily for machine processing and hex
> > strings have to be manually converted.
>
> If it is hex on normal output, it should be hex on JSON output.
> And what ever the normal output format is has to be accepted on command line
> as input.
Ah, I forgot the output == input principle in iproute2!
In any case if there was ever a vote whether to limit this principle to
non-JSON output, and make machines' life easier, I'd vote 'yes' :)
