linux-kernel - Re: [PATCH 05/14] scripts: add an script to parse the ABI files

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:   Fri, 14 Jun 2019 08:14:36 -0600
From:   Jonathan Corbet <corbet@....net>
To:     Jani Nikula <jani.nikula@...ux.intel.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        Mauro Carvalho Chehab <mchehab@...pensource.com>,
        Mauro Carvalho Chehab <mchehab@...radead.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 05/14] scripts: add an script to parse the ABI files

On Fri, 14 Jun 2019 17:00:55 +0300
Jani Nikula <jani.nikula@...ux.intel.com> wrote:

> On Fri, 14 Jun 2019, Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
> > On Fri, Jun 14, 2019 at 04:31:56PM +0300, Jani Nikula wrote:  
> >> On Thu, 13 Jun 2019, Mauro Carvalho Chehab <mchehab+samsung@...nel.org> wrote:  
> >> > From: Mauro Carvalho Chehab <mchehab@...pensource.com>
> >> >
> >> > Add a script to parse the Documentation/ABI files and produce
> >> > an output with all entries inside an ABI (sub)directory.
> >> >
> >> > Right now, it outputs its contents on ReST format. It shouldn't
> >> > be hard to make it produce other kind of outputs, since the ABI
> >> > file parser is implemented in separate than the output generator.  
> >> 
> >> Hum, or just convert the ABI files to rst directly.  
> >
> > And what would that look like?  
> 
> That pretty much depends on the requirements we want to set on both the
> ABI source files and the generated output. Obviously the requirements
> can be conflicting; might be hard to produce fancy output if the input
> is very limited.

The real question, I guess, is: is there anything else that depends on the
current format of those files?  That could make reformatting them harder.

Otherwise it seems like Jani's fieldlist idea might have some potential.
We could consider a *really* simple preprocessing step if we really wanted
("prepend a colon on relevant lines and join with the following line if
need be") to keep the current format nearly unchanged.

jon