BIND 10 #1324: Basic DHCP benchmark software framework

[BIND 10 Development]

#1324: Basic DHCP benchmark software framework
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  johnd
  stephen                            |                Status:  reviewing
                       Type:  task   |             Milestone:  Sprint-
                   Priority:  major  |  DHCP-20111123
                  Component:         |            Resolution:
  perfdhcp                           |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by johnd):

 Replying to [comment:12 stephen]:
 > Reviewed commit 0ad9b8c8482a134af7c47b64b412f642d08ce642
 >

 > '''tests/tools/perfdhcp/perfdhcp.h'''[[BR]]
 > progName[] is defined as extern - why?  As it is a constant, why not
 #define it in a header file?

 C++ tutorials & previous code review made me think this was preferred.
 I've changed it.

 > '''tests/tools/perfdhcp/procconf.cc'''[[BR]]
 > > procOpts(): In addOptVal(), the description of "last" is that it is
 used to track the last record in each option list so that option values
 can be appended easily. This implies that "last" is a pointer into the
 chain of structs whose first element is pointed to by "first". Yet in
 "procOpts()", "last" is initialized to point to a separate structure (and
 is then immediately deallocated after the call to procCmdLineArgs).
 > What is the reason for this?

 The previous commit includes more detailed/disambiguated variable naming.
 The arrays allocated in procOpts that were called first/last are used to
 track the first and last instance on a per-option basis; one element of
 each ends up being passed to addOptVal() as it processes each command line
 option.

 > > I left the extern C declarations in because these files will be
 included by the packet-display code that will be added back in. This is
 currently built as C code; the plan calls for it to built a C++ when it is
 actually rewritten as C++
 > This seems to imply that there is somthing in that code that is
 incompatible with g++; that just means work downstream when perfdhcp is
 converted to C++.  Why can't that code be made compatible with C++?

 The part that's incompatible is the use of designated initializers,
 included in C99 but lacking in C++.  In earlier discussion, among the
 various options for dealing with this immediately or later, it was decided
 that this will remain C code until perfdhcp is rewritten in C++, at which
 point it would use some form of C++ runtime initialization.

 > > and left the pc_malloc handling of allocation failure as is, to
 continue to give callers of the option processor the opportunity to
 report/exit as they see fit.
 > OK - but (a) who else is going to call the option processor, and (b)
 what can they do (other than exit) if it reports a memory allocation
 failure?

 The caller will surely exit, after decided how to report the error.  My
 inclination is that, if a mechanism exists anyway for propagating up the
 details of a failure, to use that mechanism to report even unrecoverable
 failures.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1324#comment:13>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development