All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brad Fisher <brad@info-link.net>
To: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: netfilter-devel@lists.netfilter.org,
	Henrik Nordstrom <hno@marasystems.com>
Subject: Re: [PATCH] comment match port to pom-ng
Date: Mon, 17 May 2004 11:44:44 -0500	[thread overview]
Message-ID: <40A8EBFC.4DCF5E@info-link.net> (raw)
In-Reply-To: Pine.LNX.4.33.0405141055450.21804-100000@blackhole.kfki.hu

Jozsef Kadlecsik wrote:

> Sorry, but could you demonstrate the necessity/usefulness of such a
> feature? I tried to figure out at least one, but failed.

I believe Henrik's response to this pretty much sum it up - Thanks, Henrik.  I
guess the way I am currently using this match is to mark rules which are
automatically added so they can be recognized by my scripts if they need to
modify them.  I am currently modifying my rules on a rule-by-rule basis, and
have no intermediate storage of rule structure, so the tables must contain all
relevant information.  I wanted to make sure that I could manually add rules
and be certain that my scripts would not touch them, even if they did appear
to be similar.  One can build their rule structures so that most rules are in
separate application-specific chains, but there must always be hooks from some
pre-built chain to call the custom ones, and it's primarily for rules in those
chains that I use the match.  I relieves me from doing anything more
complicated than comparing for a specific pattern in the comment.  Without it,
I'd be forced to compare all elements of the rules (ie. src, dst, matches,
etc.) just to make sure it was one my script added - and even then it wouldn't
be certain.

On a related note: I had proposed at one time an 'application' match (see:
http://marc.theaimsgroup.com/?l=netfilter-devel&m=105234664704023&w=2), so I
could do the same, but the idea for the 'comment' match that was brough up
suited my needs just as well and is more flexible/general.

I don't know if the reasons mentioned above are good enough for pom inclusion,
but I'd like to see it happen.  As far as inclusion in the stock kernel, I
guess I wouldn't feel too bad if it never made it there as long as it was in
pom.

> Best regards,
> Jozsef

Thanks,
Brad Fisher

  parent reply	other threads:[~2004-05-17 16:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-12 21:43 [PATCH] comment match port to pom-ng Brad Fisher
2004-05-14  9:09 ` Jozsef Kadlecsik
2004-05-16 12:26   ` Henrik Nordstrom
2004-05-17 13:43   ` Harald Welte
2004-05-17 16:44   ` Brad Fisher [this message]
2004-05-17 21:19     ` Jozsef Kadlecsik
2004-05-17 21:30       ` Henrik Nordstrom
2004-05-17 22:36         ` Brad Fisher
2004-05-17 23:12 ` Jozsef Kadlecsik
2004-05-18 15:06   ` Brad Fisher

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=40A8EBFC.4DCF5E@info-link.net \
    --to=brad@info-link.net \
    --cc=hno@marasystems.com \
    --cc=kadlec@blackhole.kfki.hu \
    --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.