Skip site navigation (1)Skip section navigation (2)
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>