Re: [PATCH v1 1/3] uapi: introduce kernel uAPI headers import

[Maxime Coquelin <maxime.coquelin@redhat.com>]

On 10/14/24 14:14, Maxime Coquelin wrote:
> 
> 
> On 10/9/24 16:50, Stephen Hemminger wrote:
>> On Wed,  9 Oct 2024 10:58:03 +0200
>> Maxime Coquelin <maxime.coquelin@redhat.com> wrote:
>>
>>> +fixup_includes()
>>> +{
>>> +    local path=$1
>>> +
>>> +    sed -i -E -e '
>>> +    s/([[:space:](])(__user|__force|__iomem)[[:space:]]/\1/g
>>> +    s/__attribute_const__([[:space:]]|$)/\1/g
>>> +    s@^#include <linux/compiler(|_types).h>@@
>>> +    
>>> s/(^|[^a-zA-Z0-9])__packed([^a-zA-Z0-9_]|$)/\1__attribute__((packed))\2/g
>>> +    
>>> s/(^|[[:space:](])(inline|asm|volatile)([[:space:](]|$)/\1__\2__\3/g
>>> +    s@#(ifndef|define|endif[[:space:]]*/[*])[[:space:]]*_UAPI@#\1 @
>>> +    ' $path
>>> +
>>
>>
>>
>> Rather than copy-pasting headers_install.sh, could you use it directly?
>>
>> The copy/paste from GPL-2.0 concerns me.
>> And the potential upstream change as well.
>>
> 
> The downside I see by calling directly the headers_install.sh script is
> that it could trigger some false positives if the version used for
> import is different from the one used to check.
> 
> What we could do it to just do our own sed command if that's really an
> issue, that we would tailor based on our needs.
> 
> Others, any thoughts?

Following the discussion during the DPDK Release status meeting this
morning, I will propose a new version implementing our own sed command,
tailored to only our needs.

Thanks,
Maxime

> Thanks,
> Maxime