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

[Greg Kroah-Hartman]

On Fri, Jun 14, 2019 at 05:00:55PM +0300, Jani Nikula wrote:
> On Fri, 14 Jun 2019, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > On Fri, Jun 14, 2019 at 04:31:56PM +0300, Jani Nikula wrote:
> >> On Thu, 13 Jun 2019, Mauro Carvalho Chehab <mchehab+samsung@xxxxxxxxxx> wrote:
> >> > From: Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxxxxx>
> >> >
> >> > 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.
> 
> At the bare minimum, you could convert the files to contain
> reStructuredText field lists [1]. Add a colon at the start of the field
> name, and make sure field bodies (values) are not empty.
> 
> Conversion of a file selected at random; I've only added ":" and "N/A".

N/A should be allowed to just drop the line entirely, right?

And what does this end up looking like?

I also hate "flag days" where all of a chunk of stuff needs to be
converted into another style.  Also it doesn't deal with merges from the
100+ different trees that all end up adding stuff to this directory over
time (slowly though, unfortunately)

So ideally, I'd like to keep the original format if at all possible.
Having the tool here allows people to do nice things like search for a
specific file easily, or a device type, which is something that I know I
have wanted, and others have asked for in the past as well.

It also might allow us to find out where we are missing documentation, a
long-term goal of mine.

thanks,

greg k-h