On Wed, 24 Feb 2016, David Lamparter wrote:
This rewrites Quagga's memory per-type allocation counting, without
using a fixed global list of types. Instead, source files can declare
memory types which get handled through constructor functions called by
the dynamic linker during startup.
Using the pre-processor to encode things into the symbol namespace, to
avoid runtime expenses++. :) Working on same myself.
Couple of initial comments:
- This seems to require various extensions to work, some seem to be GCC
specific?
Are there people using other compilers? (I used to regularly build
with the Sun One Studio compiler, but I don't anymore; only clang
and gcc).
How much do people value compiler portability?
- The __builtin_types_{expect,compatible_p} stuff, would C11 _Generic
allow the same to be achieved?
- Could the manipulation of the linked list global pointers (the
addition of a group onto the global groups list, then additions of
memtypes in a group onto the group list) be done behind a centralised
function in lib/memory and go through that, rather than twiddled
directly in each mtype specific constructor function?
- Compiler and linker specific extensions to arrange to declare static
stuff on by one and have a function called for each.
The key thing here really is just to not have to update the library,
right? I.e., the dynamic group registration is the more important bit?
And groups will hopefully be few (perhaps 1 per daemon - certainly in
Quagga)
If the types in a group were still kept as a table, they could be
handed to a lib/memory registration function, and standard C could be
used.
enum memtypes_bgp_c {
MEMTYPE_ENT_C(BGP_NEXTHOP),
MEMTYPE_ENT_C(BGP_ROUTE),
};
struct memtypes {
MEMTYPE_ENT(BGP_NEXTHOP, "BGP nexthop"),
MEMTYPE_ENT(BGP_ROUTE, "BGP route"),
MEMTYPE_ENT_END,
} memtypes_bgp;
somewhere in an early init func or main:
MEMTYPES_REG (BGP, memtypes_bgp);
where MEMTYPES_REG uses the appropriate func created when the BGP
group was declared to find the right group and then call a centralised
function to add it.
??
Explicitly registering the group, and then the table to the group, via
helper macros, doesn't seem like it should be onerous, given the
number of groups should be low? (with library memtypes init done
behind a library init).
I.e., I'm just wondering if non-standard construction extensions are
enough of a win, given they only eliminiate a couple of initialisation
calls?
- The formatting should follow the standard style in Quagga,
particularly anything intended for core lib/ bits.
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
"Life sucks, but death doesn't put out at all...."
-- Thomas J. Kopp
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
