[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <201010091434.42986.sven.eckelmann@gmx.de>
Date: Sat, 9 Oct 2010 14:34:41 +0200
From: Sven Eckelmann <sven.eckelmann@....de>
To: b.a.t.m.a.n@...ts.open-mesh.org
Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCHv5] net: Add batman-adv meshing protocol
David Miller wrote:
> From: Sven Eckelmann <sven.eckelmann@....de>
> Date: Sat, 18 Sep 2010 21:03:30 +0200
>
> > B.A.T.M.A.N. (better approach to mobile ad-hoc networking) is a routing
> > protocol for multi-hop ad-hoc mesh networks. The networks may be wired or
> > wireless. See http://www.open-mesh.org/ for more information and user
> > space tools.
> >
> > Signed-off-by: Sven Eckelmann <sven.eckelmann@....de>
>
> The only thing remaining which I really don't like is this hash helper
> library thing in here.
>
> It's a terrible abstraction and very inefficient. Iteration uses
> function calls, as does removal. Key comparisons use callbacks, via
> indirection function pointers, also very inefficient.
I would completely agree.
> Just use the "struct hlist_head" and "struct hlist_node" objects we
> have generically already. Inline the list iteration, as well as the
> key comparisons and the node linking/unlinking.
hlist_head and hlist_node is the right thing to do, but I am a little bit
irritated by the rest.
Ok, no hash implementation from the basics, but there is functionality shared
by the four hashing tables used, which I would not like to "implement" again
everywhere. For example the "add to hash if data isn't already added there".
This can easily done using a static inline function which receives a
comparison and choose/key function (which also can be inlined by the compiler)
and does the rest using hlist_*.
Speaks anything against such things shared in inside batman-adv only?
thanks,
Sven
Download attachment "signature.asc " of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists