netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Graf <tgraf@suug.ch>
To: Pablo Neira <pablo@eurodev.net>
Cc: netdev@oss.sgi.com, jamal <hadi@cyberus.ca>
Subject: Re: [RFC] textsearch infrastructure + skb_find_text()
Date: Thu, 5 May 2005 19:42:24 +0200	[thread overview]
Message-ID: <20050505174224.GB25977@postel.suug.ch> (raw)
In-Reply-To: <427A51A2.8090600@eurodev.net>

* Pablo Neira <427A51A2.8090600@eurodev.net> 2005-05-05 19:02
> - A custom destroy function in ts_ops.

Sure, can be added once we need it. Currently none of my
algorithms allocate anything on their own. Might be worth
to change the API and replace textsearch_put with textesearch_destroy
also freeing the configuration though.

> - I don't see a way to look for matches in fragments. I mean, say we've 
> got "dancing " in a fragment and "chicken" in the next one. Currently we 
> don't get a match.

This is implemented in skb_find_text(), I just looked through rusty's
code and it's very simliar so we could make the args in ts_state a
union of long args[6] and char cb[XXX] so we can store skb_iter
in there.

> I've been reworking the framework for string matching that I sent you 
> two/three months ago, you've definitely worked on a good base. Since 
> then I've introduced a lot of changes and actually I've been testing it 
> (ick, that means that we've clashed!).

I don't think so, my approach is quite different and allows for
optimized text searches over fragments, multiple skbs, etc without
any hacks around the fragment borders. It's a lot more generic
allowing it to be in lib/ so it can be used from other subsystem
as well.

> I think that I can merge both works and then roll on. I still need more 
> time to study more in deep your proposition.

Sure go ahead but please don't merge it into netfilter, a) the core
really is supposed to be in lib, and b) I don't want any netfilter
dependencies in my ematches.

  reply	other threads:[~2005-05-05 17:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-04 23:40 [RFC] textsearch infrastructure + skb_find_text() Thomas Graf
2005-05-05 12:42 ` jamal
2005-05-05 14:12   ` Thomas Graf
2005-05-05 17:02 ` Pablo Neira
2005-05-05 17:42   ` Thomas Graf [this message]
2005-05-06  1:33     ` Pablo Neira
2005-05-06 12:36       ` Thomas Graf
2005-05-06 13:04         ` jamal
2005-05-06 14:43           ` Thomas Graf
2005-05-07 13:03             ` Jamal Hadi Salim
2005-05-08 11:45               ` Thomas Graf
2005-05-06 21:44 ` Thomas Graf
2005-05-07  0:17   ` YOSHIFUJI Hideaki / 吉藤英明
2005-05-07  0:36     ` Thomas Graf

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=20050505174224.GB25977@postel.suug.ch \
    --to=tgraf@suug.ch \
    --cc=hadi@cyberus.ca \
    --cc=netdev@oss.sgi.com \
    --cc=pablo@eurodev.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).