Received: with ECARTIS (v1.0.0; list netdev); Sun, 16 Jan 2005 07:08:59 -0800 (PST)
Received: from b.mx.projectdream.org (eth0-0.arisu.projectdream.org [194.158.4.191])
	by oss.sgi.com (8.13.0/8.13.0) with ESMTP id j0GF8s9a004912
	for <netdev@oss.sgi.com>; Sun, 16 Jan 2005 07:08:54 -0800
Received: from postel.suug.ch (unknown [195.134.158.23])
	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
	(No client certificate requested)
	by b.mx.projectdream.org (Postfix) with ESMTP id 1896984;
	Sun, 16 Jan 2005 16:08:31 +0100 (CET)
Received: by postel.suug.ch (Postfix, from userid 10001)
	id 5710D1C0EA; Sun, 16 Jan 2005 16:09:14 +0100 (CET)
Date: Sun, 16 Jan 2005 16:09:14 +0100
From: Thomas Graf <tgraf@suug.ch>
To: jamal <hadi@cyberus.ca>
Cc: Patrick McHardy <kaber@trash.net>, netdev@oss.sgi.com
Subject: Re: [RFC] meta ematch
Message-ID: <20050116150914.GU26856@postel.suug.ch>
References: <20050108145457.GZ26856@postel.suug.ch> <1105363582.1041.162.camel@jzny.localdomain> <20050110211747.GA26856@postel.suug.ch> <1105394738.1085.63.camel@jzny.localdomain> <20050113174111.GP26856@postel.suug.ch> <41E6C3E5.2020908@trash.net> <20050113192047.GQ26856@postel.suug.ch> <41E71CC4.3020102@trash.net> <20050114151407.GR26856@postel.suug.ch> <1105887519.1097.597.camel@jzny.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1105887519.1097.597.camel@jzny.localdomain>
X-Virus-Scanned: ClamAV 0.80/650/Sun Jan  2 19:00:02 2005
	clamav-milter version 0.80j
	on 127.0.0.1
X-Virus-Status: Clean
X-archive-position: 309
X-ecartis-version: Ecartis v1.0.0
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
X-original-sender: tgraf@suug.ch
Precedence: bulk
X-list: netdev

* jamal <1105887519.1097.597.camel@jzny.localdomain> 2005-01-16 09:58
> On Fri, 2005-01-14 at 10:14, Thomas Graf wrote:
> > 
> > Here's a revised patch. I fixed the numeric comparison issues and
> > added meta_obj instead of using meta_data to give a better impression
> > on the difference of a comparable object and meta data definitions.
> 
> I scanned the code very quickly; lets start with the big picture then i
> will send some more comments:
> Did i understand this correctly that a metamatch MUST have a lvalue +
> rvalue pair?

They MAY have bove.


> What if all i wanted to say was 
> ..
> ematch indev eth0
> 
The lvalue will be TCF_META_ID_INDEV and your rvalue will be
TCF_META_TYPE_VAR with "eth0" as payload(TCF_EM_META_RVALUE).
TCF_EM_META_LVALUE will be unused in this case.