netdev - Re: [PATCH net-next v4 5/8] net: fou: regenerate the uAPI from the spec

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] [day] [month] [year] [list]

Date:   Wed, 25 Jan 2023 11:16:09 +0100
From:   Alexander Lobakin <alexandr.lobakin@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        Johannes Berg <johannes@...solutions.net>
CC:     <davem@...emloft.net>, <netdev@...r.kernel.org>,
        <edumazet@...gle.com>, <pabeni@...hat.com>, <robh@...nel.org>,
        <stephen@...workplumber.org>, <ecree.xilinx@...il.com>,
        <sdf@...gle.com>, <f.fainelli@...il.com>, <fw@...len.de>,
        <linux-doc@...r.kernel.org>, <razor@...ckwall.org>,
        <nicolas.dichtel@...nd.com>
Subject: Re: [PATCH net-next v4 5/8] net: fou: regenerate the uAPI from the
 spec

From: Jakub Kicinski <kuba@...nel.org>
Date: Tue, 24 Jan 2023 16:40:07 -0800

> On Tue, 24 Jan 2023 19:50:40 +0100 Johannes Berg wrote:
>> On Tue, 2023-01-24 at 18:49 +0100, Alexander Lobakin wrote:
>>> From: Jakub Kicinski <kuba@...nel.org>
>>> Date: Fri, 20 Jan 2023 09:50:38 -0800
>>>   
>>>> Regenerate the FOU uAPI header from the YAML spec.
>>>>
>>>> The flags now come before attributes which use them,
>>>> and the comments for type disappear (coders should look
>>>> at the spec instead).  
>>>
>>> Sorry I missed the whole history of this topic. Wanted to ask: if we can
>>> generate these headers and even C files, why ship the generated with the
>>> source code and not generate them during building? Or it's slow and/or
>>> requires some software etc.?
>>
>> Currently it requires python 3 (3.6+, I'd think?).
>>
>> Python is currently not documented as a build requirement in
>> Documentation/process/changes.rst afaict.
> 
> Yes, I wanted to avoid bundling in changes which could be controversial.
> Whether code is generated during build or committed is something we can
> revisit at any point.

+, got it, thanks!

The only reason I asked is that I was hoping it would allow us to remove
a couple thousand locs because why not :D
At least the atomic functions are designed the same way (the tree has
the generated code committed/included), so it's totally fine.

I like what this series and the idea in general does, thanks!

Olek