Re: Legacy Linux kernel support

[Mario Rugiero <mrugiero () gmail com>]

El mar., 8 oct. 2019 a las 3:59, Michael Richardson
(<mcr () sandelman ca>) escribió:
> There are many people who use prototype new things this way.
> Even IP/IPv6 stuff that use a different protocol number.   Often they move
> away from libpcap as their requirements grow, but they start that way.
>
> One reason to do this because they don't control the kernel they have to run on.
Supporting TPACKET_V2 should suffice to fill this gap, right?
We would still need to make a few changes, currently you need to use a
kernel which doesn't support TPACKET_V3 to use this correctly.
It shouldn't be a big change to make immediate mode go with
TPACKET_V2, so I guess I could do it.

> While they may be using "old" kernels, they usually aren't using ancient (jurasic) kernels.
What do we exactly mean when we talk about "old" and about "Jurassic"?
2.6.x would be old and 2.4.y would be Jurassic?

El mar., 8 oct. 2019 a las 7:58, David Laight
(<David.Laight () aculab com>) escribió:
> I don't think it makes sense to drop support for kernels which distributions still have under LTS.
> I think that means 2.6.32 still needs to be supported.
It depends.
Which distro is it?
When does it EOL?
Do we expect a release of libpcap before that?
What version of libpcap does it ship?
Do the providers ship it with custom patches?
For the "official" distro package, is it likely to have a major upgrade?
Do they currently provide bug-fixes on their own
Is it simpler to just branch away for critical fixes? Note that
patches will be backported one way or another if they don't do major
upgrades.
Considering it's an LTS, I'm guessing they don't do major upgrades and
they keep vendor patches already, so that's what they'll keep doing.

Is it a good idea for a user to do a custom build?
Are there any life changing features between then and now that can
actually be used with an old kernel?
Is it worthy losing the support you paid for for it?
The latter can obviously only be answered by the users, but since
making a census is rather impractical, I think we should make
guesstimates here.
El mar., 8 oct. 2019 a las 12:42, Michael Richardson
(<mcr () sandelman ca>) escribió:
> And that's why I think we would agree that we don't want to let tcpdump go
> all C99, etc. yet, because people often *do* want the latest tcpdump, on top
> of a kernel-compatible libpcap.
That's why we use abstraction layers, after all.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers