BIND 10 #2974: Implement Hooks Framework (part 1) - all but library loading and unloading
BIND 10 Development
do-not-reply at isc.org
Thu Jun 13 16:40:45 UTC 2013
#2974: Implement Hooks Framework (part 1) - all but library loading and unloading
-------------------------------------+-------------------------------------
Reporter: stephen | Owner: tomek
Type: task | Status:
Priority: medium | reviewing
Component: Unclassified | Milestone:
Keywords: | Sprint-DHCP-20130620
Sensitive: 0 | Resolution:
Sub-Project: DHCP | CVSS Scoring:
Estimated Difficulty: 0 | Defect Severity: N/A
Total Hours: 0 | Feature Depending on Ticket:
| Add Hours to Ticket: 0
| Internal?: 0
-------------------------------------+-------------------------------------
Changes (by stephen):
* owner: stephen => tomek
Comment:
From comment:6
'''src/lib/util/tests/callout_manager_unittest.cc'''[[BR]]
> !CalloutManagerTest constructor. I don't like the fact that there are 4
hook points defined and there is a maximum of 4 libraries. One of those
values should be changed to avoid confusion.
Changed to 10 libraries.
> You do not set callout_value_ in constructor.
Now initialized to 0.
> Why are those callouts named manager_X? I think they should be called
callout_X (or userlib_X). They represent callouts from a user library.
Naming them manager is a bit misleading. There will always be just one
manager.
Renamed to callout_X.
> !CalloutManagerTest.!CallCalloutsError: I'm somewhat uneasy with the
fact that the first library that returns an error will cause other
libraries to not be called...
I've followed the suggestion I made in my last comment and to which you
agreed: the error return from the callout is ignored, and the
SUCCESS/COMPLETE status codes have been removed. (Currently there is a
"todo" in the code to remind me to add the logging of errors when I deal
with the next ticket.)
> Skip flag is not tested.
Test has been added to the handles_unittest set of tests. (The basic
operation of the "skip" flag is tested in the callout_handle unit tests.)
> There are no tests that check that the same callout can be
registered/called/deregistered on different hook points.
(!CalloutManagerTest.!CallCalloutsSuccess checks that to some degree).
Added !MultipleCalloutsLibrariesHooks test.
From comment:7
'''src/lib/util/tests/handles_unittest.cc'''[[BR]]
> There are no dedicated tests to check if argument set/changed by one
callout are passed to the next callout (it is tested to some degree - many
of the existing tests use getArgument). It would be good to have a
dedicated test for that purpose.
Good catch. !CheckModifiedArgument test added for that purpose.
'''src/lib/util/tests/callout_handle_unittest.cc'''[[BR]]
> !CalloutHandleTest.!ContextItemNames: what's the value variable is for?
It is increased for every setArgument, but then never checked. If it not
really important (because we check names only), please add a short comment
about it.
Removed and constants used instead.
'''Extra comment about !CalloutHandle class'''[[BR]]
> Final comment is about get/setArgument. We need getConstArgument() (to
be used by library) and setConstArgument() (to be used by server only). If
this can be achived with use of existing get/setArgument template, such
capability should be demonstrated in tests (and later documented). That is
needed to pass configuration parameters. For example in select_subnet hook
point, I need to provide available subnets, so the callout can choose.
However, the callout must not modify that configuration data (there's
another interface for changing configuration data - bindctl and its
restful api).
>
> Please note that tests done in !CalloutHandleTest.!PointerTypes are not
sufficient. const Beta* x only makes the pointer constant, so it cannot be
changed, however the object it points to can be changed. We need Beta*
const x; (non-const pointer to a const object).
You are incorrect in your pointer types:
* <type>* ptr - variable pointer to variable data.
* const <type>* ptr - variable pointer to constant data.
* <type>* const ptr - constant pointer to variable data.
* const <type>* const ptr - constant pointer to constant data.
(e.g. see http://duramecho.com/ComputerInformation/WhyHowCppConst.html or
http://jriddell.org/const-in-cpp.html)
The argument list can distinguish between "<type>* ptr" and "const <type>*
ptr" and the tests check this, i.e. that if the server were to pass a
"const <type>*" pointer, the user library could only retrieve the data
into a "const <type>*" pointer. So you can pass a pointer to data that the
user library cannot modify (although there is nothing to stop the user
library calling const_cast to discard the const attribute in order to
modify the data).
Note that it doesn't make sense to copy a "const" object (as opposed to a
pointer/reference to a const object) into the argument list. You are
effectively passing it by value, and it is up to the user library what
they do with it: to avoid the value being altered in the server, don't
copy the value back from the argument list when the callout returns. (The
issue of data modification is discussed in the [wiki:Bind10HooksFramework
design document].) Besides, there are issues in that objects are copied
into the argument list and copied out from them: "const" objects can only
be set at initialization, copying into them is forbidden.
'''!ChangeLog'''[[BR]]
Suggested !ChangeLog entry:
{{{
626. [func] stephen
Added initial part of hooks framework (all but library loading).
(Trac #2974, git xxx)
}}}
--
Ticket URL: <https://bind10.isc.org/ticket/2974#comment:11>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list