On 12.06.2026 15:21, Ilya Maximets wrote: > 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. > Hi! I wanted to support builds on kernels older than 5.9, which don't have kernel-side
support for EVPN multihoming. I can do it without fully copying the header — add handling in m4 or some other option I'll think about. But the main reason I went with copying the headers is that I looked at many other open source projects, for example FRR, where headers were added specifically to support builds. And personally, I feel that if we get new features down the road, handling each one in precompilation or adding separate struct definitions — as Ilya suggested — looks dirtier to me than copying the whole header and maintaining it as things come up. But the decision is yours and I'll redo it. Thanks! _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
