linux-kernel - Re: [RFC PATCH v1 3/6] kernel-doc: add kerneldoc-lint command

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: <87bmuv5u5p.fsf@intel.com>
Date:   Wed, 25 Jan 2017 12:08:18 +0200
From:   Jani Nikula <jani.nikula@...el.com>
To:     Markus Heiser <markus.heiser@...marit.de>
Cc:     Daniel Vetter <daniel@...ll.ch>, Jonathan Corbet <corbet@....net>,
        Mauro Carvalho Chehab <mchehab@...radead.org>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Matthew Wilcox <mawilcox@...rosoft.com>,
        "linux-doc \@ vger . kernel . org List" <linux-doc@...r.kernel.org>,
        "linux-kernel \@ vger . kernel . org List" 
        <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v1 3/6] kernel-doc: add kerneldoc-lint command

On Wed, 25 Jan 2017, Markus Heiser <markus.heiser@...marit.de> wrote:
> Am 25.01.2017 um 09:21 schrieb Jani Nikula <jani.nikula@...el.com>:
>> Yes, see below. It's simplistic and it has an external dependency, but
>> it got the job done. And it does not depend on Sphinx; it's just a
>> kernel-doc and rst lint, not Sphinx lint. Whether that's a good or a bad
>> thing is debatable.
>> 
>> Anyway, I do think the approach of making 'make CHECK=the-tool C=1' work
>> is what we should aim at.
>
> Ah, cool ... didn't know C=1 before .. I will consider it in v2.
>
>> Markus' patch could probably be made to do
>> that by accepting the same arguments that are passed to compilers.
>
> Is this what you mean?

No. The build system passes the same (or roughly the same) arguments to
the CHECK tool as it passes to the compiler. You need to handle them in
your tool, possibly just ignoring them if they're not relevant.

BR,
Jani.


>
>   make W=n   [targets] Enable extra gcc checks, n=1,2,3 where
> 		1: warnings which may be relevant and do not occur too often
> 		2: warnings which occur quite often but may still be relevant
> 		3: more obscure warnings, can most likely be ignored
> 		Multiple levels can be combined with W=12 or W=123
>
> Thanks!
>
>  --Markus-- 
>

-- 
Jani Nikula, Intel Open Source Technology Center