Execute Based Class Matching

Jeffrey Hutzelman jhutz at cmu.edu
Wed Jan 28 14:03:04 UTC 2009


--On Wednesday, January 28, 2009 12:47:14 PM +0000 Patricio Latini 
<p_latini at hotmail.com> wrote:

>
> 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.

I'm not sure what you're saying here; perhaps that's just due to lack of 
sleep on my part.  You described a scenario involving a limitation of the 
hash-table-lookup approach taken for subclasses, specifically where it was 
desirable to do try more than one value from the request.  I suggested an 
approach that could be used to solve that class of problem.  It's certainly 
not as general as calling out to an arbitrary external program, and wasn't 
intended to be a substitute.




>> > > > > 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

Indeed, for some reason I was assuming that execute(...) was actually an 
expression returning the command's exit status, rather than a statement, 
analogous to the way ns-update() works.

Thus, I thought you were describing a change to the semantics of something 
already in the code, rather than a change to the new code you were working 
on.  Had I realized this I would not have objected; in fact, I believe I 
previously supported the argument that returning a data expression 
containing the output is far superior to parsing the output and returning 
an integer, since the conversion to an integer can always be done in the 
configuration language, if desired.


-- Jeff



More information about the dhcp-users mailing list