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
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.