On 6/12/26 10:19 AM, Ales Musil via dev wrote:
> On Thu, Jun 11, 2026 at 9:43 AM Alexandra Rukomoinikova via dev <
> [email protected]> wrote:
>
>> Bake in the required Linux kernel UAPI headers so that OVN builds
>> correctly against older kernel header versions that may be missing
>> certain definitions.
>>
>> Signed-off-by: Alexandra Rukomoinikova <[email protected]>
>> ---
>>
>
> Hi Alexandra,
>
> thank you for the patch. I'm afraid this is a hard nack for me
> for several reasons, we shouldn't just copy the kernel headers
> and "drag" them along in our project. It will be a maintenance
> nightmare to add new stuff when needed. Could you share
> which kernel version you need to compile against? Maybe
> we could add more exceptions to the ovn.m4 to make it work.
FWIW, it may be necessary in some cases to include the headers when the
build environment is older than the one the binary will be deployed to.
But I agree that copying the entire header should be the last resort
option.
If the full header is not actually required, then include_next should
be a preferred choice. There are couple strategies for that:
1. The minimal re-definition, if possible. Suitable if only some
macros or functions are missing:
#if !defined(WHAT_WE_NEED)
#define WHAT_IS_USED_AND_WHAT_WE_NEED_OR_NEWER
#endif
#include_next <original-header.h>
2. If we have to alter things like structs that will conflict with the
original header, then:
#if !defined(WHATEVER_WE_NEED)
#define EVERYTHING_THAT_IS_USED_IN_THE_CODE
#else
#include_next <original-header.h>
#endif
This requires re-defining everything that OVN code does actually use.
Suitable when what the code is actually using is much smaller than
the entire header.
3. Just copy the entire header. Suitable when the code is actually
using most of the header and the option 1 is not possible.
But we need to know what is actually missing before making a decision
for the strategy. The information on what is missing should be in the
commit message.
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
