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] [thread-next>] [day] [month] [year] [list]
Message-ID: <d0803cdf-e4d8-102a-d67f-d3a32a4dfff0@amd.com>
Date:   Tue, 25 Jun 2019 13:33:27 +0000
From:   Gary R Hook <ghook@....com>
To:     Jonathan Corbet <corbet@....net>, Joe Perches <joe@...ches.com>
CC:     "Hook, Gary" <Gary.Hook@....com>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>
Subject: Re: [PATCH 0/3] Clean up crypto documentation

On 6/24/19 3:37 PM, Jonathan Corbet wrote:
> On Mon, 24 Jun 2019 13:29:42 -0700
> Joe Perches <joe@...ches.com> wrote:
> 
>>> Finally, would you prefer a v2 of the patch set? Happy to do
>>> whatever is preferred, of course.
>>
>> Whatever Jonathan decides is fine with me.
>> Mine was just a plea to avoid unnecessarily
>> making the source text harder to read as
>> that's what I mostly use.
> 
> Usually Herbert seems to take crypto docs, so it's not necessarily up to
> me :)
> 
> I don't see much that's objectionable here.  But...
> 
>> I don't know if this extension is valid yet, but
>> I believe just using <function_name>() is more
>> readable as text than ``<function_name>`` or
>> :c:func:`<function_name>`
> 
> It's been "valid" since I wrote it...it's just not upstream yet :)  I
> expect it to be in 5.3, though.  So the best way to refer to a kernel
> function, going forward, is just function() with no markup needed.

So I'm unclear:

1) would you prefer I wait on your 5.3 change being fully committed,
2) add your change to my local tree and use it, then submit an update 
patchset that depends upon it, or
3) re-submit now (using the current method) with suggested changes?

I'm thinking that this will go in after the referenced patch, so (2) is 
the preferred choice?

grh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ