El mar., 8 oct. 2019 a las 3:59, Michael Richardson (<m...@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.lai...@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 (<m...@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
