From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [PATCH] CTA_PROTO_NUM is u_int8_t not u_int16_t Date: Sun, 04 Dec 2005 21:02:08 +0100 Message-ID: <43934B40.60309@trash.net> References: <438CDF45.9040308@trash.net> <4392630F.4040008@eurodev.net> <439313B2.50601@trash.net> <20051204.114813.59310147.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: laforge@netfilter.org, netfilter-devel@lists.netfilter.org, pablo@eurodev.net Return-path: To: "David S. Miller" In-Reply-To: <20051204.114813.59310147.davem@davemloft.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-devel-bounces@lists.netfilter.org Errors-To: netfilter-devel-bounces@lists.netfilter.org List-Id: netfilter-devel.vger.kernel.org David S. Miller wrote: > From: Patrick McHardy > Date: Sun, 04 Dec 2005 17:05:06 +0100 > > >>It doesn't even affect compatiblity, userspace can send both >>u_int8_t or u_int16_t, the binary representation will look the same. > > > On little-endian, yes. But on big-endian you'll get a byte-swapped > value for the case where userspace sends in a u8. Yes. Unfortunately we don't have much choice because kernel and userspace use both u_int8_t and u_int16_t for CTA_PROTO_NUM. Some ugly workarounds might be possible, but considering that ctnetlink is new and how much problems it still has, it shouldn't be a big problem to do this right and break compatibility.