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:   Sat, 12 Sep 2020 00:11:20 +0100
From:   Edward Cree <ecree@...arflare.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     Jesse Brandeburg <jesse.brandeburg@...el.com>,
        <netdev@...r.kernel.org>, <intel-wired-lan@...ts.osuosl.org>
Subject: Re: [RFC PATCH net-next v1 11/11] drivers/net/ethernet: clean up
 mis-targeted comments

On 11/09/2020 23:26, Jakub Kicinski wrote:
> "Toolchain" sounds a little grand in this context, the script that
> parses kdoc does basic regexps to convert the standard kernel macros:
> ...
> IDK if we can expect it to understand random driver's macros..
I wasn't suggesting it should _understand_ this macro, justrecognise
 when something _is_ a macro it doesn't understand, and refrain from
 warning about it in that case.
But I don't know how hard that would be to achieve — not being fluent
 in Perl, scripts/kernel-doc is mostly line noise to me.  My best
 guess is that on seeing 'DECLARE_A_THING(name, argument);' it reads
 it as though it were 'DECLARE_A_THING name, argument;', mistaking
 the macro name for a type.
I think the only way non-macro declarations can legitimately contain
 parens is in function pointer types, in which case the contents of
 the parens are part of the type and not declared identifiers.  So
 shouldn't kernel-doc ignore anything within parens?
> This is the only use of _MCDI_DECLARE_BUF() in the tree
Well, except for mcdi.h's
    #define MCDI_DECLARE_BUF(_name, _len) _MCDI_DECLARE_BUF(_name, _len) = {{{0}}}
> , how about converting the declaration to:
>
> #declare _MCDI_BUF_LEN(_len)   DIV_ROUND_UP(_len, 4)
>
> 	efx_dword_t txbuf[_MCDI_BUF_LEN(MC_CMD_PTP_IN_TRANSMIT_LENMAX)];
>
> Would that work?
That could work, yes.  Though, probably lose the leading underscore
 in that case.

-ed

Powered by blists - more mailing lists