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