Merge branch 'reciprocal'
authorDavid S. Miller <davem@davemloft.net>
Wed, 22 Jan 2014 07:19:26 +0000 (23:19 -0800)
committerDavid S. Miller <davem@davemloft.net>
Wed, 22 Jan 2014 07:19:26 +0000 (23:19 -0800)
commit374d1125237e94f16ffa3185cff62df03977a988
tree3bb15ec5b897df4ea197339478bb5d76049a2761
parent6cd28f044b47aeeba91807d97d6f3ea5a048e88d
parent809fa972fd90ff27225294b17a027e908b2d7b7a
Merge branch 'reciprocal'

Hannes Frederic Sowa says:

====================
reciprocal_divide update

This patch is on top of aee636c4809fa5 ("bpf: do not use reciprocal
divide") from Eric that sits in net tree. It will not create a merge
conflict, but it depends on this one, so we suggest, if possible, to
merge net into net-next.

We are proposing this change with only small modifications from the
v2 version, namely updating the name of trim to reciprocal_scale
(as commented on by Ben Hutchings and Eric Dumazet, thanks!).

We thought about introducing the reciprocal_divide algorithm in
parallel to the one already used by the kernel but faced organizational
issues, leading us to the conclusion that it is best to just replace
the old one: We could not come up with names for the different
implementations and also with a way to describe the differences to
guide developers which one to choose in which situation. This is
because we cannot specify the correct semantics for the version
which is currently used by the kernel. Altough it seems to not be
causing problems in the kernel, we cannot surely say so in the
case of flex_array for the future. Current usage seems ok, but
future users could run into problems.

Changelog:

v1->v2:
 - changed name to prandom_u32_max in p1
 - changed name to trim in p2
 - reworked code in p3
v2->v3:
 - p1 and p3 stays unchanged, only small update in commit
   message in p3
 - changed name to reciprocal_scale in p2
 - fixed kernel doc format
v3->v4:
 - pseduo -> pseudo (thanks to Tilman Schmidt)
v4->v5:
 - fix pseduo -> pseudo for real now, sorry for the noise
====================

Signed-off-by: David S. Miller <davem@davemloft.net>