linux-kernel - Re: [PATCH] kernel-doc: Handle returning pointers to pointers

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, 24 Jan 2017 07:58:36 +0100
From:   Markus Heiser <markus.heiser@...marit.de>
To:     Jonathan Corbet <corbet@....net>
Cc:     Matthew Wilcox <mawilcox@...rosoft.com>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kernel-doc: Handle returning pointers to pointers


Am 23.01.2017 um 16:24 schrieb Jonathan Corbet <corbet@....net>:

> On Mon, 23 Jan 2017 15:14:51 +0000
> Matthew Wilcox <mawilcox@...rosoft.com> wrote:
> 
>>> I maintain my own stack of "linuxdoc" with a python version
>>> of the kernel-doc script (hosted on github). It uses the same
>>> regexes as the perl version (using a python rewrite here has some
>>> other benefits, one you will see below). I merged your patch:  
>> 
>> Are there plans to merge that?  It feels so odd to have a python script calling a perl script ...
> 
> I pushed back pretty hard on it last year; my feeling at the time was that
> the Sphinx transition had enough moving parts as it was.

I know what you mean ;)

>  I do think we
> can reconsider it now, though.  It's not as if the perl kerneldoc script
> is a thing of great beauty in need of preservation.
> 
> Markus, would you consider sending out a new patch set for review?  

Yes, I send RFC soon ...

> What I
> would like to do see is something adding the new script for the Sphinx
> toolchain, while leaving the DocBook build unchanged, using the old
> script.  We could then delete it once the last template file has moved
> over.

agree ...

> 4.12 would be the probable merge target; it's a big enough change that I'd
> like to have it in -next for a full development cycle.

agree once more.

Thanks for choosing this!

  -- Markus --