Hi Marcel and Denis,

> I am just mentioning this here so that everybody understands what our goals here. We might be utilizing systems where the userspace is small and really limited. What ELL needs to do is provide common functionality for its users, but it does not have to solve world hunger for its users.

It's nice to get such goal clarifications, the earlier the better 
though: it was not as clear as that when we started.

That said, there are misleading signals about these. I'll be annoying 
about hashmap, last time:

If memory is at stake, why promoting a bit of performance via storing 
the hash per-entry in the hashmap?
Why also enabling the storage of the same key multiple times?
(though that should not be an issue if the code is made without bug, but 
anyway the library should help just a bit when it's not too costly.)

Why also copying the key in the hashmap, when this could be wisely 
shared with the structure it points to?
I am thinking about the network's object path. We rebuilt the object 
path dynamically, when we could be using just the same pointer.
It would only require to be careful not to destroy a network structure, 
before removing its entry in the hash.
(here it's a win/win on memory/performance)


On list - or queues - what are the arguments about using dynamically 
allocated ones vs the linux "list.h" way for instance?
Isn't the later one a bit better from memory point of view if it would 
be single linked one (as it is not if I remember well)?
(though the syntax is odd I agree, taste issue issue here so it's 
subjective).


And about the non-dbus, non-netlink ways, this would require a complete 
rewrite of the targeted projects since these are
not architectured at all for that. That's also quite new as a goal.


Cheers,

Tomasz