netdev - Re: [oss-drivers] Re: [RFC 3/4] nfp: make use of extended ack message reporting

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 26 Apr 2017 20:44:56 +0200
From:   Simon Horman <simon.horman@...ronome.com>
To:     David Miller <davem@...emloft.net>
Cc:     jhs@...atatu.com, jakub.kicinski@...ronome.com,
        netdev@...r.kernel.org, johannes@...solutions.net,
        dsa@...ulusnetworks.com, daniel@...earbox.net,
        alexei.starovoitov@...il.com, bblanco@...il.com,
        john.fastabend@...il.com, kubakici@...pl, oss-drivers@...ronome.com
Subject: Re: [oss-drivers] Re: [RFC 3/4] nfp: make use of extended ack
 message reporting

On Wed, Apr 26, 2017 at 10:44:16AM -0400, David Miller wrote:
> From: Simon Horman <simon.horman@...ronome.com>
> Date: Wed, 26 Apr 2017 13:13:16 +0200
> 
> > On Tue, Apr 25, 2017 at 10:20:22AM -0400, David Miller wrote:
> >> From: Jamal Hadi Salim <jhs@...atatu.com>
> >> Date: Tue, 25 Apr 2017 08:42:32 -0400
> >> 
> >> > So are we going to standardize these strings?
> >> 
> >> No.
> >> 
> >> > i.e what if some user has written a bash script that depends on this
> >> > string and it gets changed later.
> >> 
> >> They can't do that.
> >> 
> >> It's free form extra information an application may or not provide
> >> to the user when the kernel emits it.
> > 
> > I don't feel strongly about this and perhaps it can be revisited at some
> > point but perhaps it would be worth documenting that he strings do not
> > form part of the UAPI as my expectation would have been that they do f.e. to
> > facilitate internationalisation.
> 
> These two things are entirely separate.
> 
> We can maintain uptodate translations of the strings, yet document that
> they can change at any time and are thus not UAPI.

Thanks, I see that now.