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]

Message-ID: <20170123082429.2e48b52f@lwn.net>
Date:   Mon, 23 Jan 2017 08:24:29 -0700
From:   Jonathan Corbet <corbet@....net>
To:     Matthew Wilcox <mawilcox@...rosoft.com>
Cc:     Markus Heiser <markus.heiser@...marit.de>,
        "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

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 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?  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. 

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.

Thanks,

jon