Date: Fri, 5 Oct 2012 17:12:28 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Ermal Lu?i <eri@FreeBSD.org> Cc: net@FreeBSD.org Subject: Re: [PATCH] resolve byte order mess in ip_input/ip_output/pfil(9) Message-ID: <20121005131228.GQ34622@glebius.int.ru> In-Reply-To: <CAPBZQG0Z0Hc-DCQoyZGEwLMXB4wSsEZhyoy9zNDuXe8P8LBoQA@mail.gmail.com> References: <20121005114716.GP34622@FreeBSD.org> <CAPBZQG0Z0Hc-DCQoyZGEwLMXB4wSsEZhyoy9zNDuXe8P8LBoQA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ermal, On Fri, Oct 05, 2012 at 03:01:38PM +0200, Ermal Lu?i wrote: E> it would be better to switch to net byte order allover rather than E> trade one for the other. E> This makes it even more tricky to understand the code than it is. E> If you do the work its better to do the full thing in one shot and E> switch to netbyte order. Please read carefully my description and patch. It creates a definite points in stack where byte order is swapped. One point where it is swapped into host, and one point where it is swapped back into net. Patch already narrows down the scope of host byte order in the stack, host byte order is now between to definite points. If anyone ever wants to switch entire stack to net byte order, let it be. Current patch is just step in this direction. The fast forwarding path is already entirely in net byte order. Even if run with ipfw and/or pf. E> speaking of pf(4) side of things please do not loose the VIMAGE calls! Yeah, can you explain please why do we need them here? The pfil hooks are always run already in some defined VNET context, don't they? -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121005131228.GQ34622>