Message-ID: <C236CECE-702B-4410-A509-9D33F51392C2@oracle.com>
Date:   Sat, 4 Mar 2023 19:48:51 +0000
From:   Chuck Lever III <chuck.lever@...cle.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     Chuck Lever <cel@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>,
        "open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
        "kernel-tls-handshake@...ts.linux.dev" 
        <kernel-tls-handshake@...ts.linux.dev>,
        John Haxby <john.haxby@...cle.com>
Subject: Re: [PATCH v6 1/2] net/handshake: Create a NETLINK service for
 handling handshake requests


> On Mar 4, 2023, at 2:16 PM, Jakub Kicinski <kuba@...nel.org> wrote:
> 
> On Sat, 4 Mar 2023 17:44:34 +0000 Chuck Lever III wrote:
>>> I couldn't find a way to have the generated source appear
>>> in the middle of a source file. But I see that's not the
>>> way others are doing it, so I have added separate files
>>> under net/handshake for the generated source and header
>>> material. Two things, though:
>>> 
>>> 1. I don't see a generated struct genl_family.  
>> 
>> Some experimentation revealed that this is because the spec
>> was a "genetlink-c" spec which prevents the generation of
>> "struct genl_family".
>> 
>> But switching it to a "genetlink" spec means it wants my
>> main header to be linux/handshake.h, and it won't allow the
>> use of "uapi-header" to put that header somewhere else (in
>> my case, I thought linux/net/handshake.h was more appropriate).
> 
> Hm, include/uapi/linux/net/ does not exist and I did not foresee
> the need :)  We just need to allow it in the schema, right?
> 
> diff --git a/Documentation/netlink/genetlink.yaml b/Documentation/netlink/genetlink.yaml
> index 62a922755ce2..5594410963b5 100644
> --- a/Documentation/netlink/genetlink.yaml
> +++ b/Documentation/netlink/genetlink.yaml
> @@ -33,6 +33,9 @@ additionalProperties: False
>   protocol:
>     description: Schema compatibility level. Default is "genetlink".
>     enum: [ genetlink ]
> +  uapi-header:
> +    description: Path to the uAPI header, default is linux/${family-name}.h
> +    type: string
> 
>   definitions:
>     description: List of type and constant definitions (enums, flags, defines).

Somehow it's working as I had it. I can't fathom where the
generated source file is including include/uapi/linux/handshake.h
from, but <shrug> it's generating properly and compiling now.

I see others, such as fou, also appear to work just the
same way as I structured it. So, false alarm, I hope.


>>> 2. The SPDX tags in the generated source files is "BSD
>>>  3-clause", but the tag in my spec is "GPL-2.0 with
>>>  syscall note". Oddly, the generated uapi header still
>>>  has the latter (correct) tag.
> 
> I was trying to go with least restrictive licenses for the generated
> code. Would BSD-3-clause everywhere be okay with you?

IIUC we cannot generate source code from a GPL-encumbered
specification and label that code with a less-restrictive
license. Isn't generated source code a "derived" artifact?

The spec lives in the kernel tree, therefore it's covered.
Plus, my employer requires that all of my contributions
to the Linux kernel are under GPL v2.

I'd prefer to see all my generated files get a license
that matches the spec's license.

You could add an spdx object in the YAML schema, and output
the value of that object as part of code generation.

To be safe, I'd also find a suitably informed lawyer who
can give us an opinion about how this needs to work. I've
had a similar discussion about the license status of a
spec derived from source code, so I'm skeptical that we
can simply replace the license when going to code from
spec.

If you need to require BSD-3-clause in this area, I can
request an exception from my employer for the YAML that
is contributed as part of the handshake mechanism.

Sorry to make trouble -- hopefully this discussion is also
keeping you out of trouble too.


--
Chuck Lever

Powered by blists - more mailing lists