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. Makefile.am guideline (Francis Dupont)
2. check exception messages (Francis Dupont)
3. throughts about footprint (Francis Dupont)
----------------------------------------------------------------------
Message: 1
Date: Thu, 03 Sep 2015 12:24:10 +0000
From: Francis Dupont <[email protected]>
To: [email protected]
Subject: [kea-dev] Makefile.am guideline
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
This is a proposal for a new Makefile.am section of coding guidelines.
First when there is a least a subdirectory the SUBDIRS entry, e.g.:
SUBDIRS = . tests
Followed by AM_CPPFLAGS set to source and build tree at the second level
and external dependency includes and CPPFLAGS, e.g.:
AM_CPPFLAGS = -I$(top_srcdir)/src/lib -I$(top_builddir)/src/lib
AM_CPPFLAGS += $(BOOST_INCLUDES)
Directory variables should be relative (i.e., no abs_top_builddir)
for efficiency.
Third (or more) levels should not be used, e.g.:
NO += -I$(top_srcdir)/src/lib/dns -I$(top_builddir)/src/lib/dns
AM_CXXFLAGS should be initialized to KEA_CXXFLAGS, e.g.:
AM_CXXFLAGS = $(KEA_CXXFLAGS)
When executables are build, AM_LDFLAGS must be conditionally set
to static, e.g.:
if USE_STATIC_LINK
AM_LDFLAGS = -static
endif
At the exception of archives, (dynamic) libraries and executables should
be linked with all dependencies in the opposite order of src/lib/Makefile.am
for shared libraries (so finishing by libkea-exceptions.la) followed
y external dependencies. The idea is to not rely on libtool which has
shown some problems handling dependencies.
Dynamic Shared Objects built as modules to be dynamically loaded must have
no dependency when static linking is enforced: their undefined symbols
should be resolved using executables they are loaded into.
PS: please comment/improve if you think this should not go as it is
into coding guidelines.
Regards
Francis Dupont <[email protected]>
------------------------------
Message: 2
Date: Thu, 03 Sep 2015 12:38:54 +0000
From: Francis Dupont <[email protected]>
To: [email protected]
Subject: [kea-dev] check exception messages
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
The idea to extend gtest with new macros checking exception messages
(#3889) was not adopted but the idea is still applicable by writing
explicit checks as the moduleSpecError() routine in
src/lib/config/tests/module_spec_unittests.cc
So I propose:
- to add something about this in coding guidelines, e.g.:
when the same exception can be raised with different and sensible
error messages these messages should be explicitly checked
in unit tests.
- create a new ticket to address cases which clearly should be improved.
Regards
Francis Dupont <[email protected]>
------------------------------
Message: 3
Date: Thu, 03 Sep 2015 13:14:58 +0000
From: Francis Dupont <[email protected]>
To: [email protected]
Subject: [kea-dev] throughts about footprint
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
These thoughts are supposed to address this action item "Write
extended coding guidelines that take into consideration the
memory/binary footprint" (PS: partially (i.e., new ideas are wellcome)
and of course for decreasing the footprint.
First idea: maximize sharing. There are some points where something
can be done:
- optimize for space (g++ -Os)
- enable link time optimization (great but platform dependent)
- instantiate header or mainly header class code: this is required
by visibility (which needs something to export) but has an unknown
action on a memory size, i.e., it is possible we should optionally
extract some class code from headers.
- don't abuse of inlining (it seems the current code is reasonable:
it relies on the compiler suite to do its best).
- share template instantiation (there is a dedicated feature for
this: makes templates "extern": it is a C++ 11 feature but already
available by default in many compilers).
Second idea: use the visibility feature. This removes unneeded
relocations (drastic decrease of binary sizes) and helps some
optimizations.
Third idea: chase memory leaks. We already use valgrind but they are
other tools we could try.
Forth idea: implement a region class (a la bind 9) which allows to
share a buffer, for instance a part of a DHCP message. Today the
only way to extract a part of an input buffer is to allocate some
space and to copy this part into it. Even a pessimistic evaluation
of this should win the half of currently used buffer space.
Regards
Francis Dupont <[email protected]>
PS: most of these points are already in the visibility ticket.
The last 2 are not really coding guidelines...
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 18, Issue 2
**************************************
