kernel versioning

[Paul Wouters]

On Sun, 12 Mar 2006, Arjan van de Ven wrote:

> well API changes are one of the prices you pay for being an outside
> module, and is not unique to Fedora.
>
> The entire kernel development model is setup for having everything in
> one repo, and everything outside that is just painful. See that as
> incentive to get your code merged ;)

Well, in theory one would hope that API changes in "vendor kernels" would
not be needed. After all the linuS kernel is the "experimental" kernel,
and the "vendor" kernels are supposed to be stable ones. So ideally, the
Fedora kernel would only have bugfixes, not API changes.

But it is a price we'll pay. Networking code isn't always in flux as it
has been, so most of the time it is okay. We would like to get our UDP
encapsulation patch ("IPsec NAT-Traversal patch") code in Fedora, since
right now, the ESPinUDP code is located in the XFRM code, while the KLIPS
version of this code is more general and within the udp.c code, which
unfortunately requires a kernel recompile. This patch has been in use
for years, and is pretty small, but we haven't yet submitted it for
review to Fedora or upstream. Part of the reason was that lots of people
got (rightfully so) pissed off at the FreeS/WAN politics, and although
Openswan does not have these issues, that clear cut hasn't been clear to
everyone yet. Another reason was that we were hoping to perhaps change
the code to a netfilter module, which could then be a loadable kernel
module, which is perhaps a cleaner approach and more appropriate.

Though the NAT-T patch rock solid. It has been used for many years without
known issues, so if the kernel people for Fedora would want to apply the
nat-t patch, that would of course rock! :)
(Or even just add it and define it to be disabled per default so, we can
just tell them to rpmbuild the kernel with a --define 'natt-patch=1'.

ftp://ftp.openswan.org/openswan/openswan-2.4.5rc5.kernel-2.4-natt.patch.gz

Paul