On Mon, 2005-01-03 at 10:02, Thomas Graf wrote:
> > ok. I realize its optional - but i wouldnt even give the writter of
> > ematch the opportunity to write one. Want something more complex? write
> > a classifier.
> A classifier is at least 300 lines and you lose the ability to use the
> logic relations.
Sure, but simpler-than-classifier is where we started ;->
I think in time we should revamp this a little more, but classifiers we
have today already we just cant get rid of them now. Over time, I agree
we should revamp.
> > Again allowing for this may be overkill. Just send the same structure
> > the ematch needs in exactly the same form it needs it and you dont need
> > this.
> Compromise: If change/dump is not provided the api allocates and
> memcpy's itself resptively dumps m->data. Simple ematches don't have to
> care and can simple access m->data, more complex ematches can implement
> their own change/dump. Does that sound beter?
Yes, indeed. A copy instead of reference is owned by the classifier.
To me its a valid compromise. Dont want those matches to be shared
in any case. Also dont want user to know shit about TLVs.
Neither in the kernel, nor in user space. Simplicty.
Sorry, havent looked at the code yet. Is the patch you posted the same
as you have on the url earlier?
> > whats the .link for?
> I use list.h to chain ematch_ops and it's better to have it initialized.
I relaized that - but should the user know anything about this?