linux-kernel - Re: [PATCH] crypto: clear htmldocs build warnings for crypto/hash

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]

Date:   Tue, 9 Jan 2018 02:56:19 +1100
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     Kamil Konieczny <k.konieczny@...tner.samsung.com>
Cc:     "Tobin C. Harding" <me@...in.cc>,
        "David S. Miller" <davem@...emloft.net>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] crypto: clear htmldocs build warnings for crypto/hash

On Mon, Jan 08, 2018 at 02:11:21PM +0100, Kamil Konieczny wrote:
> 
> 
> On 07.01.2018 00:01, Tobin C. Harding wrote:
> > SPHINX build emits multiple warnings of kind:
> > 
> > 	warning: duplicate section name 'Note'
> > 
> > (when building kernel via make target 'htmldocs')
> > 
> > This is caused by repeated use of comments of form:
> > 
> > 	* Note: soau soaeusoa uoe
> > 
> > We can change the format without loss of clarity and clear the build
> > warnings.
> > 
> > Add '**[mandatory]**' or '**[optional]**' as kernel-doc field element
> > description prefix
> > 
> > This renders in HTML as (prefixes in bold)
> > 
> > final
> >     [mandatory] Retrieve result from the driver. This function finalizes the
> >     transformation and retrieves the resulting hash from the driver and
> >     pushes it back to upper layers. No data processing happens at this
> >     point unless hardware requires it to finish the transformation (then
> >     the data buffered by the device driver is processed).
> > 
> > Signed-off-by: Tobin C. Harding <me@...in.cc>
> > ---
> > 
> > This patch begs the question why the other members of struct ahash_alg
> > are not marked? Some are marked 'optional' some 'mandatory'. It would
> > seem that if the marking were necessary for some members it is necessary
> > for all to eliminate ambiguity?
> > 
> > thanks
> 
> import, export are optional

No import/export must be implemented for all hashes.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt