Execute Based Class Matching

Wed Jan 28 12:47:14 UTC 2009

> Date: Tue, 27 Jan 2009 23:00:13 -0500> From: jhutz at cmu.edu> To: dhcp-users at lists.isc.org; dhcp-users at isc.org> Subject: RE: Execute Based Class Matching> CC: jhutz at cmu.edu> > --On Wednesday, January 28, 2009 02:51:15 AM +0000 Patricio Latini > <p_latini at hotmail.com> wrote:> > > The problem i have seen with using subclasses for this is how flexible> > and dynamic the could be, for instance if I want to match agent.remote-id> > of an incoming packet with the hardware address of an existing client> > (subclass) to see if the packet is passing though a "known" device, i> > have two keep to subclass tables, one for the hardware of the device and> > other for the agent.remote-id of the client both containing virtually the> > same info.> > Oh, that's unfortunate. You essentially want to match two different > expressions against the same hash table. I'm pretty sure this doesn't work > today, but I don't see why the server couldn't be extended to allow a > parent class to contain more than one "match" (not "match if") statement, > with the semantics that each expression is evaluated and looked up, and the > class matches if any of the lookups succeed.

I agree your point that the server can be extended to do anything we want to, however i have executed() the coding and completed the action to have 
the desired outcome done that by the way is not only limited to that simple example i posted.
> > > > > With this approach, with small changes to the return> > parser (accept full strings instead of just integers)> > Except that's not a small change; it discards the exit status of a command > (which, among other things, tells us whether it succeeded) in favor of its > output. That may be desirable for some cases, but I wouldn't advocate > changing the existing semantics of execute().> 
If you take a look at the actual source code, it is not taking the return status of the function at all, it is only using that value &status if waitpid() to confirm the fork() worked ok, this is kept in my patch. In the original source code execute_statement: is not return()ing anything. So the patch does not changes that behaivor at all...
With all respect, I would like to ask you that next time to critisize somebody's work in the future to take a look of it before, you would have found that the patch i did uses a diferent semantic and code when execute is executed than when is evaluated as a expresion. The new execute function could have been named returnexecute()....

> > > Regading how to improve this,> > in order to reduce the number of execute() statements, i have been trying> > to make a set myvalue=execute(...); match if (myvalue=x); in the first> > subclass; and then if the following classes are related (that they use> > the same execute parameters), just do the match if (myvalue=x).> > That approach won't work, because those lines don't run in the order you > think they do. "set" is an executable statement and is processed fairly > late, after we've determined that the client is a member of the class (and > that we're going to give it a lease, and for what address). The "match if" > is _not_ an executable statement; it's a special property of the class, and > the expression is evaluated when deciding whether the client is a member of > that class.> > -- Jeff

I have posted my patch to make it available for everybody as could be useful as it is for me and some other people that are using it. Anybody who find it interesting can use it by just patching the source and/or if the DHCP developers see that the idea is interesting or that many people likes it can implement it in the main code or not.
I am not interested in pushing this patch to the main code tree as with my very little C knowledge as i can make that patch work any time the source code changed but after using lot of years the ISC DHCP code i felt i needed to share with the open source comunity any improvement i have done. 

Best Regards

Patricio> _______________________________________________> dhcp-users mailing list> dhcp-users at lists.isc.org> https://lists.isc.org/mailman/listinfo/dhcp-users
_________________________________________________________________
Windows Live™: E-mail. Chat. Share. Get more ways to connect. 
http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_allup_howitworks_012009
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090128/638574eb/attachment-0001.html>