Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Re: How to properly test callouts? (Marcin Siodelski)
2. Re: How to properly test callouts? (Marcin Wyszynski)
3. Re: How to properly test callouts? (Tomek Mrugalski)
4. Re: How to properly test callouts? (Francis Dupont)
5. Re: How to properly test callouts? (Marcin Wyszynski)
----------------------------------------------------------------------
Message: 1
Date: Wed, 05 Nov 2014 16:05:37 +0100
From: Marcin Siodelski <[email protected]>
To: Marcin Wyszynski <[email protected]>, [email protected]
Subject: Re: [kea-dev] How to properly test callouts?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Marcin,
The hook libraries are normally compiled as shared libraries and loaded
by Kea from the specific location indicated in the Kea configuration.
I am not certain from your description, but it seems that you haven't
built your library as a shared module so it cannot be dynamically loaded
by Kea?
There is a good example of the hooks library, that we have implemented
for our needs, in the source code. It is located in
src/hooks/dhcp/user_chk. It comes along with the suitable Makefile.am
which builds it as a shared library. It also has a bunch of unit tests
for individual C++ classes and methods. I think it will be best for you
to start from there. It is also well documented in the developer's
guide:
http://git.kea.isc.org/~tester/kea/doxygen/d8/db2/libdhcp_user_chk.html
Apart from this, the developer's guide comprises a collection of other
documents about the hooks framework which you may find useful, e.g.
http://git.kea.isc.org/~tester/kea/doxygen/df/d46/hooksdgDevelopersGuide.html
or http://git.kea.isc.org/~tester/kea/doxygen/de/df3/dhcpv4Hooks.html
It is possible that I misunderstood your intent and you want to test
your library in a different way than loading it as a shared library. If
so, please be more specific what you're actually going to achieve.
Regards,
Marcin Siodelski
DHCP Software Engineer
at ISC
On 11/05/14 00:43, Marcin Wyszynski wrote:
> Dear KEA devs,
>
> I have a statically linked hook library which I?d like to test and I?d want
> to know what the best approach would be. My naive attempt was to create an
> empty CalloutHandle object, pass it to my hook function and compare the
> result with my expectations. However, that is not so simple. CalloutHandle
> constructor expects at least a boost::shared_ptr<CalloutManager>.
> Unfortunately I see no way to create an actual instance since
> hooks/callout_manager.h header file is not explicitly exported.
>
> Please kindly advise on the best way of dealing with this problem.
>
> Thank you in advance!
>
> Best,
> Marcin
>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
>
------------------------------
Message: 2
Date: Wed, 5 Nov 2014 10:01:34 -0800
From: Marcin Wyszynski <[email protected]>
To: Marcin Siodelski <[email protected]>, <[email protected]>
Subject: Re: [kea-dev] How to properly test callouts?
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello Marcin,
thank you for a rapid response. Due to a build system constraints here at
Facebook we are not able to create shared libraries - all binaries have to be
statically linked.?
We essentially have:
extern "C" {
int pkt4_receive(CalloutHandle& handle) {
? // our implementation;
}
// other functions;
} ?// extern
The question now is - if I want to test my pkt4_receive function, how do I
create a CalloutHandle if the definition for CalloutManager needed for the only
CalloutHandle constructor is explicitly not exported? It would be awesome if
for our purposes CalloutManager could be created in a test suite:
class MyTest : public ::testing::Test {
?protected:
? virtual void SetUp() {
? ? manager_.reset(new CalloutManager(0));
? ? handle_.reset(new CalloutHandle(manager_));
? }
? boost::shared_ptr<::isc::hooks::CalloutManager> manager_;
? std::unique_ptr<::isc::hooks::CalloutHandle> handle_;
};
TEST_F(MyTest, Receive4) {
? // test our pkt4_receive function.
}
Hope that makes sense.
Best,
Marcin
On 5 November 2014 at 07:06:43, Marcin Siodelski ([email protected]) wrote:
> Marcin,
>
> The hook libraries are normally compiled as shared libraries and loaded
> by Kea from the specific location indicated in the Kea configuration.
>
> I am not certain from your description, but it seems that you haven't
> built your library as a shared module so it cannot be dynamically loaded
> by Kea?
>
> There is a good example of the hooks library, that we have implemented
> for our needs, in the source code. It is located in
> src/hooks/dhcp/user_chk. It comes along with the suitable Makefile.am
> which builds it as a shared library. It also has a bunch of unit tests
> for individual C++ classes and methods. I think it will be best for you
> to start from there. It is also well documented in the developer's
> guide:
> https://urldefense.proofpoint.com/v1/url?u=http://git.kea.isc.org/~tester/kea/doxygen/d8/db2/libdhcp_user_chk.html&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=P7u4XlV5ewRTs6xgjSUnNg%3D%3D%0A&m=BpbaF5POloTn0uJU1FZdTj1%2Fg7VAFoiR4NvSUnS%2FnFY%3D%0A&s=7a37e891ddaeda41a3fe6cd37f30102686c9378cc2c9676fd5045b35cacdaa39
>
>
> Apart from this, the developer's guide comprises a collection of other
> documents about the hooks framework which you may find useful, e.g.
> https://urldefense.proofpoint.com/v1/url?u=http://git.kea.isc.org/~tester/kea/doxygen/df/d46/hooksdgDevelopersGuide.html&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=P7u4XlV5ewRTs6xgjSUnNg%3D%3D%0A&m=BpbaF5POloTn0uJU1FZdTj1%2Fg7VAFoiR4NvSUnS%2FnFY%3D%0A&s=2cb582b0cd2ca63c8dae6a74b997289567372b181716c050181ef5950c1f2c90
>
> or
> https://urldefense.proofpoint.com/v1/url?u=http://git.kea.isc.org/~tester/kea/doxygen/de/df3/dhcpv4Hooks.html&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=P7u4XlV5ewRTs6xgjSUnNg%3D%3D%0A&m=BpbaF5POloTn0uJU1FZdTj1%2Fg7VAFoiR4NvSUnS%2FnFY%3D%0A&s=92d19ff5053799721a3a0b92eb5af0c33670faa5d873d04e1dad8b68da862ac6
>
>
> It is possible that I misunderstood your intent and you want to test
> your library in a different way than loading it as a shared library. If
> so, please be more specific what you're actually going to achieve.
>
> Regards,
>
> Marcin Siodelski
> DHCP Software Engineer
> at ISC
>
>
> On 11/05/14 00:43, Marcin Wyszynski wrote:
> > Dear KEA devs,
> >
> > I have a statically linked hook library which I?d like to test and I?d want
> > to know what
> the best approach would be. My naive attempt was to create an empty
> CalloutHandle object,
> pass it to my hook function and compare the result with my expectations.
> However, that
> is not so simple. CalloutHandle constructor expects at least a
> boost::shared_ptr.
> Unfortunately I see no way to create an actual instance since
> hooks/callout_manager.h
> header file is not explicitly exported.
> >
> > Please kindly advise on the best way of dealing with this problem.
> >
> > Thank you in advance!
> >
> > Best,
> > Marcin
> >
> > _______________________________________________
> > kea-dev mailing list
> > [email protected]
> > https://urldefense.proofpoint.com/v1/url?u=https://lists.isc.org/mailman/listinfo/kea-dev&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=P7u4XlV5ewRTs6xgjSUnNg%3D%3D%0A&m=BpbaF5POloTn0uJU1FZdTj1%2Fg7VAFoiR4NvSUnS%2FnFY%3D%0A&s=c84130d2aa6d801db7a05b615ffe188342c9266a82f673ff8a906b72dfaee3d9
> >
> >
>
------------------------------
Message: 3
Date: Wed, 05 Nov 2014 19:37:01 +0100
From: Tomek Mrugalski <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] How to properly test callouts?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 05.11.2014 19:01, Marcin Wyszynski wrote:
> Hello Marcin,
Hello Marcins ;)
> The question now is - if I want to test my pkt4_receive function, how do I
> create a CalloutHandle if the definition for CalloutManager needed for the
> only CalloutHandle constructor is explicitly not exported?
It's done on purpose, so users don't create it. The reason is that we
don't want people to go too deeply with the server side code when
implementing hooks. The reason for this is that we may change something
deep inside the code in future releases. If you just use hooks API, your
application should recompile and run fine. On the other hand, if you
take use of how currently the code is implemented, you may experience
issues when we change something.
Having said that, this is open source, so we can't really forbid that.
We're just trying to discourage people.
> It would be awesome if for our purposes CalloutManager could be created in a
> test suite:
Have you looked at HooksDhcpv4SrvTest.Buffer4ReceiveSimple,
HooksDhcpv4SrvTest.buffer4ReceiveValueChange,
HooksDhcpv4SrvTest.pkt4ReceiveSimple,
HooksDhcpv4SrvTest.valueChange_pkt4_receive,
HooksDhcpv4SrvTest.pkt4ReceiveDeleteClientId in
src/bin/dhcp4/tests/dhcp4_srv_unittest.cc?
They are relatively simple tests that are simulating packet reception to
trigger buffer4_receive and pkt4_receive (and other hook points).
Maybe you could build your unit-tests upon them?
On a related note, your request for this came at a really bad time.
Marcin and I are in the final preparation stages for IETF and a vacation
afterwards.
I just saw your pull request. It's very simple - just export the header.
I suppose we can do that :)
Hope that helps,
Tomek
------------------------------
Message: 4
Date: Wed, 05 Nov 2014 19:08:32 +0000
From: Francis Dupont <[email protected]>
To: Marcin Siodelski <[email protected]>
Cc: [email protected], Marcin Wyszynski <[email protected]>
Subject: Re: [kea-dev] How to properly test callouts?
Message-ID: <[email protected]>
> There is a good example of the hooks library, that we have
> implemented for our needs, in the source code. It is located in
> src/hooks/dhcp/user_chk. It comes along with the suitable
> Makefile.am which builds it as a shared library.
=> in fact it is a loadable module, not a shared library even on
systems using ELF they look the same (but not on OS X for instance).
> It also has a bunch of unit tests for individual C++ classes and
> methods. I think it will be best for you to start from there.
=> unfortunately the unit tests don't load the module:
- in old code the module source files are compiled in
- in current (master / #3629) code the module is linked with the unit tests
- in future (#3631 fix) code the module source files are collected
into a convenience archive which is linked with both the module
and the unit tests (the idea of the archive is to compile these files
once)
So there is currently no test code which loads the module the way
it is supposed to be loaded, i.e., via dlopen(). Note there is a
ticket (#3633) still opened about this mess (it was for an issue
introduced by #3629, fixed by #3631 but very related).
Regards
Francis Dupont <[email protected]>
PS: I wrote a lot of PKCS#11 code which is explicitely specified to
be a module, both because there is no choice on Windows (loadable module ==
dynamically linked shared object == DLL) and because it makes very easy
to restrict the entry points to a strictly limited list.
PPS: there are unit tests loading modules but in another place:
src/lib/hooks/test
------------------------------
Message: 5
Date: Wed, 5 Nov 2014 11:20:35 -0800
From: Marcin Wyszynski <[email protected]>
To: Marcin Siodelski <[email protected]>, Francis Dupont
<[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] How to properly test callouts?
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
I submitted a pull request on GitHub to expose CalloutManager for our testing
purposes.
Best,
Marcin
On 5 November 2014 at 11:08:39, Francis Dupont ([email protected]) wrote:
> > There is a good example of the hooks library, that we have
> > implemented for our needs, in the source code. It is located in
> > src/hooks/dhcp/user_chk. It comes along with the suitable
> > Makefile.am which builds it as a shared library.
>
> => in fact it is a loadable module, not a shared library even on
> systems using ELF they look the same (but not on OS X for instance).
>
> > It also has a bunch of unit tests for individual C++ classes and
> > methods. I think it will be best for you to start from there.
>
> => unfortunately the unit tests don't load the module:
> - in old code the module source files are compiled in
>
> - in current (master / #3629) code the module is linked with the unit tests
>
> - in future (#3631 fix) code the module source files are collected
> into a convenience archive which is linked with both the module
> and the unit tests (the idea of the archive is to compile these files
> once)
>
> So there is currently no test code which loads the module the way
> it is supposed to be loaded, i.e., via dlopen(). Note there is a
> ticket (#3633) still opened about this mess (it was for an issue
> introduced by #3629, fixed by #3631 but very related).
>
> Regards
>
> Francis Dupont
>
> PS: I wrote a lot of PKCS#11 code which is explicitely specified to
> be a module, both because there is no choice on Windows (loadable module ==
> dynamically linked shared object == DLL) and because it makes very easy
> to restrict the entry points to a strictly limited list.
> PPS: there are unit tests loading modules but in another place:
> src/lib/hooks/test
>
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 8, Issue 2
*************************************
