<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.linux.network">
    <title>gmane.linux.network</title>
    <link>http://permalink.gmane.org/gmane.linux.network</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.network/269571"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.network/269570"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.network/269568"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.network/269567"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.network/269566"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.network/269565"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.network/269564"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.network/269563"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.network/269562"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.network/269561"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.network/269560"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.network/269553"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.network/269552"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.network/269551"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.network/269549"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.network/269545"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.network/269544"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.network/269538"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.network/269536"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.network/269535"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.network/269571">
    <title>linux-next: manual merge of the akpm tree with the net-next tree</title>
    <link>http://permalink.gmane.org/gmane.linux.network/269571</link>
    <description>&lt;pre&gt;Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
arch/sparc/net/bpf_jit_comp.c between commit 5199dfe531db ("sparc:
bpf_jit_comp: can call module_free() from any context") from the net-next
tree and commit "bpf: add comments explaining the schedule_work()
operation" from the akpm tree.

The former means that the latter is no longer reqired, so I used the
former and can carry the fix as necessary (no action is required).

&lt;/pre&gt;</description>
    <dc:creator>Stephen Rothwell</dc:creator>
    <dc:date>2013-05-20T04:11:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.network/269570">
    <title>Re: [PATCH] vhost: get 2% performance improved by reducing spin_lock race in vhost_work_queue</title>
    <link>http://permalink.gmane.org/gmane.linux.network/269570</link>
    <description>&lt;pre&gt;
Make sense to me but need generate a patch against net-next.git or
vhost.git in git.kernel.org.

Btw. How did you test this? Care to share the perf numbers?

Thanks

&lt;/pre&gt;</description>
    <dc:creator>Jason Wang</dc:creator>
    <dc:date>2013-05-20T03:38:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.network/269568">
    <title>Re: [PATCH net-next v3] MPLS: Add limited GSO support</title>
    <link>http://permalink.gmane.org/gmane.linux.network/269568</link>
    <description>&lt;pre&gt;
I agree that is likely. I will see about making it so.


Sorry about that, yes, I meant to type MPLS.
&lt;/pre&gt;</description>
    <dc:creator>Simon Horman</dc:creator>
    <dc:date>2013-05-20T03:20:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.network/269567">
    <title>Re: [PATCH net-next v2] net: Loosen constraints for recalculating checksum in skb_segment()</title>
    <link>http://permalink.gmane.org/gmane.linux.network/269567</link>
    <description>&lt;pre&gt;
Thanks, I have updated and reposted the patch accordingly.
I also update the change log to try and make things clearer.

&lt;/pre&gt;</description>
    <dc:creator>Simon Horman</dc:creator>
    <dc:date>2013-05-20T03:19:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.network/269566">
    <title>Re: [PATCH net-next v3] MPLS: Add limited GSO support</title>
    <link>http://permalink.gmane.org/gmane.linux.network/269566</link>
    <description>&lt;pre&gt;
Thanks. I have made a patch to implement that and it seems to
both reduce the size of struct sk_buff and leave a hole for inner_protocol.

I will also update this patch to guard inner_protocol with
#ifdef CONFIG_NET_MPLS_GSO in struct sk_buff as it is otherwise unused.


&lt;/pre&gt;</description>
    <dc:creator>Simon Horman</dc:creator>
    <dc:date>2013-05-20T03:18:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.network/269565">
    <title>[PATCH] vhost: get 2% performance improved by reducing spin_lock race in vhost_work_queue</title>
    <link>http://permalink.gmane.org/gmane.linux.network/269565</link>
    <description>&lt;pre&gt;Right now the wake_up_process func is included in spin_lock/unlock, but it could be done outside the spin_lock.
I have test it with kernel 3.0.27 and guest suse11-sp2, it provide 2%-3% net performance improved.

Signed-off-by: Chuanyu Qin &amp;lt;qinchuanyu&amp;lt; at &amp;gt;huawei.com&amp;gt;
--- a/drivers/vhost/vhost.c     2013-05-20 10:36:30.000000000 +0800
+++ b/drivers/vhost/vhost.c     2013-05-20 10:36:54.000000000 +0800
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -144,9 +144,10 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
        if (list_empty(&amp;amp;work-&amp;gt;node)) {
                list_add_tail(&amp;amp;work-&amp;gt;node, &amp;amp;dev-&amp;gt;work_list);
                work-&amp;gt;queue_seq++;
+               spin_unlock_irqrestore(&amp;amp;dev-&amp;gt;work_lock, flags);
                wake_up_process(dev-&amp;gt;worker);
-       }
-       spin_unlock_irqrestore(&amp;amp;dev-&amp;gt;work_lock, flags);
+       } else
+               spin_unlock_irqrestore(&amp;amp;dev-&amp;gt;work_lock, flags);
 }
 
 void vhost_poll_queue(struct vhost_poll *poll)
&lt;/pre&gt;</description>
    <dc:creator>Qinchuanyu</dc:creator>
    <dc:date>2013-05-20T03:06:25</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.network/269564">
    <title>provide vhost thread per virtqueue for forwarding scenario</title>
    <link>http://permalink.gmane.org/gmane.linux.network/269564</link>
    <description>&lt;pre&gt;Vhost thread provide both tx and rx ability for virtio-net. 
In the forwarding scenarios, tx and rx share the vhost thread, and throughput is limited by single thread.

So I did a patch for provide vhost thread per virtqueue, not per vhost_net.

Of course, multi-queue virtio-net is final solution, but it require new version of virtio-net working in guest.
If you have to work with suse10,11, redhat 5.x as guest, and want to improve the forward throughput,
using vhost thread per queue seems to be the only solution.

I did the test with kernel 3.0.27 and qemu-1.4.0, guest is suse11-sp2, and then two vhost thread provide 
double tx/rx forwarding performance than signal vhost thread. 
The virtqueue of vhost_blk is 1, so it still use one vhost thread without change.

Is there something wrong in this solution? If not, I would list patch later.

Best regards
King
&lt;/pre&gt;</description>
    <dc:creator>Qinchuanyu</dc:creator>
    <dc:date>2013-05-20T02:11:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.network/269563">
    <title>Re: [PATCH] vhost-scsi: Depend on NET for memcpy_fromiovec</title>
    <link>http://permalink.gmane.org/gmane.linux.network/269563</link>
    <description>&lt;pre&gt;
Acked-by: Asias He &amp;lt;asias&amp;lt; at &amp;gt;redhat.com&amp;gt;


&lt;/pre&gt;</description>
    <dc:creator>Asias He</dc:creator>
    <dc:date>2013-05-20T02:07:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.network/269562">
    <title>[PATCH net-next v3] net: Loosen constraints for recalculating checksum in skb_segment()</title>
    <link>http://permalink.gmane.org/gmane.linux.network/269562</link>
    <description>&lt;pre&gt;This is a generic solution to resolve a specific problem that I have observed.

If the encapsulation of an skb changes then ability to offload checksums
may also change. In particular it may be necessary to perform checksumming
in software.

An example of such a case is where a non-GRE packet is received but
is to be encapsulated and transmitted as GRE.

Another example relates to my proposed support for for packets
that are non-MPLS when received but MPLS when transmitted.

The cost of this change is that the value of the csum variable may be
checked when it previously was not. In the case where the csum variable is
true this is pure overhead. In the case where the csum variable is false it
leads to software checksumming, which I believe also leads to correct
checksums in transmitted packets for the cases described above.

Further analysis:

This patch relies on the return value of can_checksum_protocol()
being correct and in turn the return value of skb_network_protocol(),
used to provide the protocol para&lt;/pre&gt;</description>
    <dc:creator>Simon Horman</dc:creator>
    <dc:date>2013-05-20T01:46:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.network/269561">
    <title>[RESEND PATCH net-next] xfrm: add LINUX_MIB_XFRMACQUIREERROR statistic counter</title>
    <link>http://permalink.gmane.org/gmane.linux.network/269561</link>
    <description>&lt;pre&gt;When host ping its peer, ICMP echo request packet triggers IPsec
policy, then host negotiates SA secret with its peer. After IKE
installed SA for OUT direction, but before SA for IN direction
installed, host get ICMP echo reply from its peer. At the time
being, the SA state for IN direction could be XFRM_STATE_ACQ,
then the received packet will be dropped after adding
LINUX_MIB_XFRMINSTATEINVALID statistic.

Adding a LINUX_MIB_XFRMACQUIREERROR statistic counter for such
scenario when SA in larval state is much clearer for user than
LINUX_MIB_XFRMINSTATEINVALID which indicates the SA is totally
bad.

Signed-off-by: Fan Du &amp;lt;fan.du&amp;lt; at &amp;gt;windriver.com&amp;gt;
---
 include/uapi/linux/snmp.h |    1 +
 net/xfrm/xfrm_input.c     |    5 +++++
 net/xfrm/xfrm_proc.c      |    1 +
 3 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/include/uapi/linux/snmp.h b/include/uapi/linux/snmp.h
index df2e8b4..3d072bf 100644
--- a/include/uapi/linux/snmp.h
+++ b/include/uapi/linux/snmp.h
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -287,6 +287,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; enum
 LINUX_MIB_XFRMOU&lt;/pre&gt;</description>
    <dc:creator>Fan Du</dc:creator>
    <dc:date>2013-05-20T01:40:25</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.network/269560">
    <title>Re: [PATCH] net: irda: using kzalloc() instead of kmalloc() to avoid strncpy() issue.</title>
    <link>http://permalink.gmane.org/gmane.linux.network/269560</link>
    <description>&lt;pre&gt;
Thank you, too.


Thanks.
&lt;/pre&gt;</description>
    <dc:creator>Chen Gang</dc:creator>
    <dc:date>2013-05-20T01:04:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.network/269553">
    <title>Re: [PATCH net-next] Documentation/sysctl/net.txt: fix (attribute removal).</title>
    <link>http://permalink.gmane.org/gmane.linux.network/269553</link>
    <description>&lt;pre&gt;From: Rami Rosen &amp;lt;ramirose&amp;lt; at &amp;gt;gmail.com&amp;gt;
Date: Fri, 17 May 2013 22:10:34 +0300


Applied, thanks.
&lt;/pre&gt;</description>
    <dc:creator>David Miller</dc:creator>
    <dc:date>2013-05-19T22:13:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.network/269552">
    <title>Re: [PATCH] net: irda: using kzalloc() instead of kmalloc() to avoid strncpy() issue.</title>
    <link>http://permalink.gmane.org/gmane.linux.network/269552</link>
    <description>&lt;pre&gt;From: Chen Gang &amp;lt;gang.chen&amp;lt; at &amp;gt;asianux.com&amp;gt;
Date: Fri, 17 May 2013 17:13:04 +0800


Applied, thanks.
&lt;/pre&gt;</description>
    <dc:creator>David Miller</dc:creator>
    <dc:date>2013-05-19T22:11:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.network/269551">
    <title>Re: [RESEND PATCH net-next v2] ipv6: add support of peer address</title>
    <link>http://permalink.gmane.org/gmane.linux.network/269551</link>
    <description>&lt;pre&gt;From: Nicolas Dichtel &amp;lt;nicolas.dichtel&amp;lt; at &amp;gt;6wind.com&amp;gt;
Date: Fri, 17 May 2013 10:32:00 +0200


Applied, thanks Nicolas.
&lt;/pre&gt;</description>
    <dc:creator>David Miller</dc:creator>
    <dc:date>2013-05-19T22:10:01</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.network/269549">
    <title>[PATCH] 3c59x: remove useless VORTEX_PCI() invocations</title>
    <link>http://permalink.gmane.org/gmane.linux.network/269549</link>
    <description>&lt;pre&gt;It's suboptimal to invoke quite complex VORTEX_PCI() macro every time we want
to get a 'struct pci_dev *' when we already have it in a variable... 

Signed-off-by: Sergei Shtylyov &amp;lt;sergei.shtylyov&amp;lt; at &amp;gt;cogentembedded.com&amp;gt;

---
The patch is against the Dave's 'net-next' repo. 

 drivers/net/ethernet/3com/3c59x.c |   17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

Index: net-next/drivers/net/ethernet/3com/3c59x.c
===================================================================
--- net-next.orig/drivers/net/ethernet/3com/3c59x.c
+++ net-next/drivers/net/ethernet/3com/3c59x.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1473,7 +1473,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int vortex_probe1(struct device *
 
 if (pdev) {
 vp-&amp;gt;pm_state_valid = 1;
- pci_save_state(VORTEX_PCI(vp));
+ pci_save_state(pdev);
  acpi_set_WOL(dev);
 }
 retval = register_netdev(dev);
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -3233,21 +3233,20 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static void vortex_remove_one(struct pci
 vp = netdev_priv(dev);
 
 if (vp-&amp;gt;cb_fn_base)
-pci_iounmap(VORTEX_PCI(vp), vp-&amp;gt;cb_fn_base);
+pci_iounmap(pdev, vp-&amp;gt;cb_fn_ba&lt;/pre&gt;</description>
    <dc:creator>Sergei Shtylyov</dc:creator>
    <dc:date>2013-05-19T20:17:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.network/269545">
    <title>Re: [PATCH] bridge: netfilter: using strlcpy() instead of strncpy()</title>
    <link>http://permalink.gmane.org/gmane.linux.network/269545</link>
    <description>&lt;pre&gt;Op 17/05/2013 10:07, Chen Gang schreef:
Acked-by: Bart De Schuymer &amp;lt;bdschuym&amp;lt; at &amp;gt;pandora.be&amp;gt;


&lt;/pre&gt;</description>
    <dc:creator>Bart De Schuymer</dc:creator>
    <dc:date>2013-05-19T19:43:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.network/269544">
    <title>Re: [PATCH v2] 3c59x: fix PCI resource management</title>
    <link>http://permalink.gmane.org/gmane.linux.network/269544</link>
    <description>&lt;pre&gt;Hello.

On 05/06/2013 10:23 PM, Sergei Shtylyov wrote:


    It appears I had fixes for only a small part of 
scripts/checkpatch.pl complaints
in this driver:

total: 114 errors, 428 warnings, 3327 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
       scripts/cleanfile

    I guess you don't need me to clean up the coding style in such an 
old driver,
and I don't want to spend time on it either. So I'm going to let the lot 
of overly
long lines in the driver live forever. :-)

WBR, Sergei

&lt;/pre&gt;</description>
    <dc:creator>Sergei Shtylyov</dc:creator>
    <dc:date>2013-05-19T19:36:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.network/269538">
    <title>[patch] isdn/kcapi: fix a small underflow</title>
    <link>http://permalink.gmane.org/gmane.linux.network/269538</link>
    <description>&lt;pre&gt;In get_capi_ctr_by_nr() and get_capi_appl_by_nr() the parameter comes
from skb-&amp;gt;data.  The current code can underflow to one space before the
start of the array.

The sanity check isn't needed in __get_capi_appl_by_nr() but I changed
it to match the others.

Signed-off-by: Dan Carpenter &amp;lt;dan.carpenter&amp;lt; at &amp;gt;oracle.com&amp;gt;

diff --git a/drivers/isdn/capi/kcapi.c b/drivers/isdn/capi/kcapi.c
index 9b1b274..c123709 100644
--- a/drivers/isdn/capi/kcapi.c
+++ b/drivers/isdn/capi/kcapi.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -93,7 +93,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; capi_ctr_put(struct capi_ctr *ctr)
 
 static inline struct capi_ctr *get_capi_ctr_by_nr(u16 contr)
 {
-if (contr - 1 &amp;gt;= CAPI_MAXCONTR)
+if (contr &amp;lt; 1 || contr - 1 &amp;gt;= CAPI_MAXCONTR)
 return NULL;
 
 return capi_controller[contr - 1];
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -103,7 +103,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static inline struct capi20_appl *__get_capi_appl_by_nr(u16 applid)
 {
 lockdep_assert_held(&amp;amp;capi_controller_lock);
 
-if (applid - 1 &amp;gt;= CAPI_MAXAPPL)
+if (applid &amp;lt; 1 || applid - 1 &amp;gt;= CAPI_MAXAPPL)
 return NULL;
 
 return capi_applications[applid - 1];
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -111,7 +&lt;/pre&gt;</description>
    <dc:creator>Dan Carpenter</dc:creator>
    <dc:date>2013-05-19T18:36:36</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.network/269536">
    <title>Re: [PATCH v2] net: dm9000: Allow instantiation using device tree</title>
    <link>http://permalink.gmane.org/gmane.linux.network/269536</link>
    <description>&lt;pre&gt;
OK, sorry, I should have checked that.


It seems the caller tracking is supported in subset of the kernel 
configurations.


As long as it is ENOMEM and the driver core reports failed probe I wouldn't
really care. Nevertheless I saw patch series removing such already existing
"Not enough memory" kind of error logs from the kernel, pointing out that mm
already provides relevant error logging.

Thanks,
Sylwester
&lt;/pre&gt;</description>
    <dc:creator>Sylwester Nawrocki</dc:creator>
    <dc:date>2013-05-19T17:18:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.network/269535">
    <title>Re: [PATCH net-next] x86: bpf_jit_comp: secure bpf jit against spraying attacks</title>
    <link>http://permalink.gmane.org/gmane.linux.network/269535</link>
    <description>&lt;pre&gt;
Great work !

Probably other archs could later on follow-up with setting to read-only, too.

Reviewed-by: Daniel Borkmann &amp;lt;dborkman&amp;lt; at &amp;gt;redhat.com&amp;gt;
&lt;/pre&gt;</description>
    <dc:creator>Daniel Borkmann</dc:creator>
    <dc:date>2013-05-19T17:02:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.network/269533">
    <title>RFC EOIP Tunnel</title>
    <link>http://permalink.gmane.org/gmane.linux.network/269533</link>
    <description>&lt;pre&gt;Hi,

EOIP is a proprietary ethernet over IP tunneling protocol introduced
by MikroTik's commercial product RouterOS. It uses GRE as protocol id
but with non-standard header.

Unlike EtherIP (RFC 3378) that is documented but not used, EOIP is not
documented but used for transparent Layer2 over wireless links and in
providing Layer2 services through multiple management domain networks
where pure L2 is as hard as near to impossible.

Long story short: my primary motivation behind doing this work was to
reduce the number of points of failure in a Linux+RouterOS and many
RouterOS endpoints setup. Old RouterOS endpoints do not support any
standard ethernet tunneling (upgrading is not an option) while Linux
does not support the EOIP protocol. On the other hand RouterOS cannot
be as flexible as Linux can be for routing and magic.

Judging from the existence of at least two separate opensource
projects doing this tunneling in userspace
(https://github.com/katuma/eoip and
https://code.google.com/p/linux-eoip/) I belie&lt;/pre&gt;</description>
    <dc:creator>Boian Bonev</dc:creator>
    <dc:date>2013-05-19T15:31:40</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.network">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.network</link>
  </textinput>
</rdf:RDF>
