lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 28 Aug 2020 20:39:05 -0700
From:   Roopa Prabhu <roopa@...dia.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
CC:     Roopa Prabhu <roopa@...ulusnetworks.com>, <dsahern@...il.com>,
        <netdev@...r.kernel.org>
Subject: Re: [PATCH iproute2 net-next] iplink: add support for protodown
 reason


On 8/21/20 6:30 PM, Stephen Hemminger wrote:
> External email: Use caution opening links or attachments
>
>
> On Fri, 21 Aug 2020 14:09:14 -0700
> Roopa Prabhu <roopa@...dia.com> wrote:
>
>> On 8/20/20 10:18 PM, Roopa Prabhu wrote:
>>> On 8/20/20 9:36 PM, Stephen Hemminger wrote:
>>>>
>>>> On Thu, 20 Aug 2020 20:52:02 -0700
>>>> Roopa Prabhu <roopa@...ulusnetworks.com> wrote:
>>>>
>>>>> +     if (tb[IFLA_PROTO_DOWN]) {
>>>>> +             if (rta_getattr_u8(tb[IFLA_PROTO_DOWN]))
>>>>> +                     print_bool(PRINT_ANY,
>>>>> +                                "proto_down", " protodown on ", true);
>>>> In general my preference is to use print_null() for presence flags.
>>>> Otherwise you have to handle the false case in JSON as a special case.
>>>
>>> ok, i will look. But this is existing code moved into a new function and
>>> has been
>>>
>>> working fine for years.
>>
>> looked at print_null and switching to that results in a change in output
>> for existing protodown
>>
>> attribute, so I plan to leave it as is for now.
>>
> Sure we should really try and have some consistency in the JSON output.
> Maybe a JSON style guide is needed, I wonder if some heavy JSON user already
> has one?

yes, agreed. I think we need to checkin a guide for coders and 
reviewers. specifically for the iproute2 json library.

Its hard to catch these at review time otherwise and most of iproute2 
bugs are propagated due to copy-paste.

I checked if the FRR project had one as they have a lot of json routing 
operational data. They don't and  rely on reviewers.

In the least i think the json library api documentation and a few best 
practices will help.

thanks for the review.

Powered by blists - more mailing lists