All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Peter.Riley@hotpop.com
Cc: Jan Engelhardt <jengelh@computergmbh.de>,
	netfilter-devel@lists.netfilter.org
Subject: Re: [PATCH] Last vestiges of NFC
Date: Fri, 31 Aug 2007 18:19:28 +0200	[thread overview]
Message-ID: <46D83F90.5060600@trash.net> (raw)
In-Reply-To: <46D824EA.1060406@hotpop.com>

Peter Riley wrote:
> Jan Engelhardt wrote:
>> On Aug 30 2007 08:13, Peter Riley wrote:
>>> Patrick McHardy wrote:
>>>> I count 132 occurences of nfcache (a few are in headers that must stay
>>>> though). I'll happily apply a patch that kills them all.
>>>>
>>> Patrick, yes I get 134 occurrences on 132 lines in current svn.
>>> The breakdown appears to me to be:
>> [...]
>>
>> Do we still need nfcache anyway?
>>
> 
> It seems to me there are three options....
> 
> [...]
>    Forget about ass-backwards compatibility and purge your cache!


We don't care about binary compatiblity between different userspace
releases. All we care about is not breaking userspace<->kernel
compatiblity.

> Alter the
>    iptables extension API in xtables.h so the function prototypes for ->init()
>    and ->parse() stop causing all the crap to be passed. But leave the really
>    hard ob-struct-ion in your ipt_entry. It may be too painful to reach that
>    deep down into the kernel to remove it.
> 
>    Then, you can flush out all of those toxins in the extensions and cleanse
>    the calls to them in iptables.c.  Those nasty blockages that iptables can't
>    purge because of the (a->nfcache != b->nfcache) comparison can be rooted out
>    too (as in #1).
> 
>    But let's be realistic, the fresh healthy feeling won't last forever.
>    The next time you come down with a bug and really need to make a dump,
>    dump_entry() should still be able to pass the bits of cache out of your
>    ipt_entry.  At least keep this bit:  printf("Cache: %08X ", e->nfcache);


The kernel doesn't use it, its *always* zero.

> Behind curtain #3: Is that a goat? a gnu?  No, a penguin!!
>          (Plus we'll let your friends can keep their enemas.  Penguin gets one too!)
> 
>    Go deeper, purge every last one of the 134 stinky bits of nfcache! The iptables
>    headers change as before, and now kernel headers ip_tables.h and ip6_tables.h
>    can drop nfcache in struct ipt_entry/compat_ipt_entry/ip6t_entry.  Even get rid
>    of the #define NFC_* in ./include/linux/netfilter*.h.  Hold nothing back...

Thats not possible since it breaks userspace <-> kernel compatiblity.

I prefer to get rid of all of them where possible, but if you want
to do only #1, thats also fine.

  reply	other threads:[~2007-08-31 16:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-25 17:21 [PATCH] Last vestiges of NFC Peter Riley
2007-08-25 18:07 ` Peter Riley
2007-08-29 16:58   ` Patrick McHardy
2007-08-30 15:13     ` Peter Riley
2007-08-30 18:40       ` Jan Engelhardt
2007-08-31 14:25         ` Peter Riley
2007-08-31 16:19           ` Patrick McHardy [this message]
2007-09-01 19:31             ` Peter Riley
2007-09-01 19:57               ` Peter Riley
2007-09-02 12:01                 ` Patrick McHardy
2007-09-02 11:59               ` Patrick McHardy
2007-08-31  9:38       ` Patrick McHardy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46D83F90.5060600@trash.net \
    --to=kaber@trash.net \
    --cc=Peter.Riley@hotpop.com \
    --cc=jengelh@computergmbh.de \
    --cc=netfilter-devel@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.