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 (was Re: CTA_PROTO_NUM u_int8_t or u_int16_t) Date: Wed, 23 Nov 2005 02:06:35 +0100 Message-ID: <4383C09B.7000200@trash.net> References: <4381DF77.2030704@eurodev.net> <4381FDF8.6030508@trash.net> <43820874.2050708@eurodev.net> <4382A19D.9090201@trash.net> <43836BAF.2050501@eurodev.net> <20051122220606.GC31478@sunbeam.de.gnumonks.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Pablo Neira , Netfilter Development Mailinglist Return-path: To: Harald Welte In-Reply-To: <20051122220606.GC31478@sunbeam.de.gnumonks.org> 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 Harald Welte wrote: > It can be fixed without any compatibility issues, at least in one > direction. > > If the new kernel accepts both a 8 bit and 16bit value, then new > userspace programs (who send 8bit) and old userspace programs would run > on new kernels. only for old kernels you need the old app. > > another alternative was to introduce a new CTA_PROTO_NUM8 value, which > is more explicit (but somehow stupid). Lets do that and call it CTA_PROTO, I don't like the _NUM anyway :)