* Christian Weisgerber <[email protected]> [2014-04-19 00:30]: > On 2014-04-18, Henning Brauer <[email protected]> wrote: > > so, what are we doing with this now? > > I still want to hide in_cksum_phdr() and kill in_cksum_addword() so that > > nobody ever uses that sh*t again. > > yes, sk loses is half-baked cksum offload support with this, as > > discussed before. > > as naddy pointed out there are (at least) two private copies of > > in_cksum_phdr in other drivers, that is a seperate issue in my book if > > it is an issue at all, that's not an exposed API > And I would prefer all three drivers to handle this in a consistent > way. I don't care too much if they all have private copies, make > use of in_cksum_phdr() etc., or lose this "half-baked cksum offload > support" altogether.
we're in the same boat here - it's ust that "I don't care too much either way" (both of us) doesn't really help in taking a decision :/ > Well, having three private copies would be kind of stupid. my main concern is getting rid of the in_cksum_phdr (yes yes, tehre is a SECOND function doing essentially the same, but one thing after the other) and especially in_cksum_addword "APIs". Nobody shall use this horror again. -- Henning Brauer, [email protected], [email protected] BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
