netdev - Re: [RFC PATCH net-next v1 11/11] drivers/net/ethernet: clean up mis-targeted comments

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: <115bce2a-daaa-a7c5-3c48-44ce345ea008@solarflare.com>
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