Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[RFC\]\s+textsearch\s+infrastructure\s+\+\s+skb_find_text\(\)\s*$/: 28 ]

Total 28 documents matching your query.

1. [RFC] textsearch infrastructure + skb_find_text() (score: 1)
Author: Thomas Graf <tgraf@xxxxxxx>
Date: Thu, 5 May 2005 01:40:36 +0200
The patch below is a report on the current state of the textsearch infrastructure and its first user skb_find_text(). The textsearch is kept as simple as possible but advanced enough to handle non-li
/archives/netdev/2005-05/msg00175.html (31,156 bytes)

2. Re: [RFC] textsearch infrastructure + skb_find_text() (score: 1)
Author: xxxxxxxxxxxxxx>
Date: Thu, 05 May 2005 08:42:17 -0400
How is this different from libqsearch? IIRC, it also kept pointers and callbacks. BTW, I hope theres sync with libqsearch - at least some canibalization of ideas. Also hopefully, pluggin of ne algori
/archives/netdev/2005-05/msg00197.html (12,221 bytes)

3. Re: [RFC] textsearch infrastructure + skb_find_text() (score: 1)
Author: l@xxxxxxxxxxxx>
Date: Thu, 5 May 2005 16:12:22 +0200
* jamal <1115296937.7680.52.camel@xxxxxxxxxxxxxxxxxxxxx> 2005-05-05 08:42 The main difference is that my infrastructure is much simpler. I read the libqsearch code but fixing up all the issues requir
/archives/netdev/2005-05/msg00204.html (11,818 bytes)

4. Re: [RFC] textsearch infrastructure + skb_find_text() (score: 1)
Author: ou@xxxxxxxxxxx>
Date: Thu, 05 May 2005 19:02:26 +0200
Hi Thomas, Thomas Graf wrote: The patch is separated into 3 parts, the first one being the textsearch infrastructure itself followed by a simple Knuth-Morris-Pratt implementation for reference. I'm a
/archives/netdev/2005-05/msg00207.html (11,345 bytes)

5. Re: [RFC] textsearch infrastructure + skb_find_text() (score: 1)
Author: r@xxxxxxxxxxxx>
Date: Thu, 5 May 2005 19:42:24 +0200
* Pablo Neira <427A51A2.8090600@xxxxxxxxxxx> 2005-05-05 19:02 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
/archives/netdev/2005-05/msg00211.html (10,615 bytes)

6. Re: [RFC] textsearch infrastructure + skb_find_text() (score: 1)
Author: xxxxxxxxxxxxxx>
Date: Fri, 06 May 2005 03:33:34 +0200
Thomas Graf wrote: * Pablo Neira <427A51A2.8090600@xxxxxxxxxxx> 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 an
/archives/netdev/2005-05/msg00271.html (13,150 bytes)

7. Re: [RFC] textsearch infrastructure + skb_find_text() (score: 1)
Author: adi@xxxxxxxxxx>
Date: Fri, 6 May 2005 14:36:39 +0200
* Pablo Neira <427AC96E.2020208@xxxxxxxxxxx> 2005-05-06 03:33 This is not required, I will elaborate the core logic to clarify this. I guess you still think of the logic as: function find-text(patter
/archives/netdev/2005-05/msg00297.html (14,430 bytes)

8. Re: [RFC] textsearch infrastructure + skb_find_text() (score: 1)
Author: <tgraf@xxxxxxx>
Date: Fri, 06 May 2005 09:04:08 -0400
[..] I dont see any difference between the two in terms of state storage. Can you really avoid storing state? Can you give an example? It depends on the search algorithm - if it is small, you benefit
/archives/netdev/2005-05/msg00298.html (11,743 bytes)

9. Re: [RFC] textsearch infrastructure + skb_find_text() (score: 1)
Author: aber@xxxxxxxxx>
Date: Fri, 6 May 2005 16:43:08 +0200
* jamal <1115384649.7660.140.camel@xxxxxxxxxxxxxxxxxxxxx> 2005-05-06 09:04 The state is kept on the stack since there is only one call to the algorithm's search function per match iteration. Look at
/archives/netdev/2005-05/msg00304.html (14,507 bytes)

10. Re: [RFC] textsearch infrastructure + skb_find_text() (score: 1)
Author: bunk@xxxxxxxxx>
Date: Fri, 6 May 2005 23:44:37 +0200
Quite silly regular expression implementation for textsearch infrastructure. Still has issues with textsearch_next() and can probably be optimized a lot but should be a good base to work on. diff -Nr
/archives/netdev/2005-05/msg00325.html (22,262 bytes)

11. Re: [RFC] textsearch infrastructure + skb_find_text() (score: 1)
Author: oshfuji@xxxxxxxxxxxxxx>
Date: Sat, 07 May 2005 09:17:44 +0900 (JST)
Would you add some reference(s) on algorithm etc.? Thanks. --yoshfuji
/archives/netdev/2005-05/msg00343.html (9,757 bytes)

12. Re: [RFC] textsearch infrastructure + skb_find_text() (score: 1)
Author: 明 <yoshfuji@xxxxxxxxxxxxxx>
Date: Sat, 7 May 2005 02:36:13 +0200
* YOSHIFUJI Hideaki / ?$B5HF#1QL@ <20050507.091744.106860599.yoshfuji@xxxxxxxxxxxxxx> 2005-05-07 09:17 Comes out of my own mind which means it's probably pretty poor, it simply takes a deterministic
/archives/netdev/2005-05/msg00344.html (9,711 bytes)

13. Re: [RFC] textsearch infrastructure + skb_find_text() (score: 1)
Author: xxxxxx>
Date: Sat, 07 May 2005 09:03:04 -0400
Ok, makes sense - in the case of a string spanning multi skbs, i suppose it wouldnt matter, correct? [..] I got it. I suppose in the case of text contained within one skb this would be an improvement
/archives/netdev/2005-05/msg00359.html (12,104 bytes)

14. Re: [RFC] textsearch infrastructure + skb_find_text() (score: 1)
Author: ravin <pravin.shelar@xxxxxxxxx>
Date: Sun, 8 May 2005 13:45:39 +0200
* Jamal Hadi Salim <1115470985.19561.58.camel@xxxxxxxxxxxxxxxxxxxxx> 2005-05-07 Strings spanning multiple skbs can be handled just like a paged skbs _iff_ all skbs are known at the point the search s
/archives/netdev/2005-05/msg00367.html (11,377 bytes)

15. [RFC] textsearch infrastructure + skb_find_text() (score: 1)
Author: Thomas Graf <tgraf@xxxxxxx>
Date: Thu, 5 May 2005 01:40:36 +0200
The patch below is a report on the current state of the textsearch infrastructure and its first user skb_find_text(). The textsearch is kept as simple as possible but advanced enough to handle non-li
/archives/netdev/2005-05/msg01464.html (31,156 bytes)

16. Re: [RFC] textsearch infrastructure + skb_find_text() (score: 1)
Author: jamal <hadi@xxxxxxxxxx>
Date: Thu, 05 May 2005 08:42:17 -0400
How is this different from libqsearch? IIRC, it also kept pointers and callbacks. BTW, I hope theres sync with libqsearch - at least some canibalization of ideas. Also hopefully, pluggin of ne algori
/archives/netdev/2005-05/msg01486.html (12,281 bytes)

17. Re: [RFC] textsearch infrastructure + skb_find_text() (score: 1)
Author: Thomas Graf <tgraf@xxxxxxx>
Date: Thu, 5 May 2005 16:12:22 +0200
* jamal <1115296937.7680.52.camel@xxxxxxxxxxxxxxxxxxxxx> 2005-05-05 08:42 The main difference is that my infrastructure is much simpler. I read the libqsearch code but fixing up all the issues requir
/archives/netdev/2005-05/msg01493.html (11,912 bytes)

18. Re: [RFC] textsearch infrastructure + skb_find_text() (score: 1)
Author: Pablo Neira <pablo@xxxxxxxxxxx>
Date: Thu, 05 May 2005 19:02:26 +0200
Hi Thomas, Thomas Graf wrote: The patch is separated into 3 parts, the first one being the textsearch infrastructure itself followed by a simple Knuth-Morris-Pratt implementation for reference. I'm a
/archives/netdev/2005-05/msg01496.html (11,423 bytes)

19. Re: [RFC] textsearch infrastructure + skb_find_text() (score: 1)
Author: Thomas Graf <tgraf@xxxxxxx>
Date: Thu, 5 May 2005 19:42:24 +0200
* Pablo Neira <427A51A2.8090600@xxxxxxxxxxx> 2005-05-05 19:02 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
/archives/netdev/2005-05/msg01500.html (10,693 bytes)

20. Re: [RFC] textsearch infrastructure + skb_find_text() (score: 1)
Author: Pablo Neira <pablo@xxxxxxxxxxx>
Date: Fri, 06 May 2005 03:33:34 +0200
- 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
/archives/netdev/2005-05/msg01560.html (13,430 bytes)


This search system is powered by Namazu