[Top] [All Lists]

Re: [PATCH 1/6] PKT_SCHED: Extended Matches API

To: Patrick McHardy <kaber@xxxxxxxxx>
Subject: Re: [PATCH 1/6] PKT_SCHED: Extended Matches API
From: Thomas Graf <tgraf@xxxxxxx>
Date: Mon, 24 Jan 2005 01:59:50 +0100
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <41F447CE.6030007@xxxxxxxxx>
References: <20050123230012.GB23931@xxxxxxxxxxxxxx> <20050123230132.GC23931@xxxxxxxxxxxxxx> <41F43D6D.30502@xxxxxxxxx> <20050124004929.GK23931@xxxxxxxxxxxxxx> <41F447CE.6030007@xxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
* Patrick McHardy <41F447CE.6030007@xxxxxxxxx> 2005-01-24 01:56
> Thomas Graf wrote:
> >* Patrick McHardy <41F43D6D.30502@xxxxxxxxx> 2005-01-24 01:12
> > 
> >
> >>gcc assumes likely for ptr != NULL by default. Is there a reason why a 
> >>match
> >>wouldn't have a match function ?
> >>
> >
> >There is no reason but ematches might get written by unexperienced people
> >forgeting to register it. I know, the if partly hides the failure, it's
> >one of theses case where I have the same arguments for both ways.
> >
> I don't care much, but I guess people forgetting to add a match
> function to an ematch will find other ways to do stupid things :)
> How about catching it in tcf_em_register ?

Sounds like a good plan, will do so. Thanks.

<Prev in Thread] Current Thread [Next in Thread>