Re: [PATCH 28/29] net/: rename net_random() to prandom_u32()

[Neil Horman]

On Tue, Dec 25, 2012 at 08:47:26PM +0900, Akinobu Mita wrote:
> 2012/12/25 Neil Horman <nhorman@xxxxxxxxxxxxx>:
> > On Mon, Dec 24, 2012 at 11:14:15AM +0900, Akinobu Mita wrote:
> >> Use more preferable function name which implies using a pseudo-random
> >> number generator.
> >>
> >> Signed-off-by: Akinobu Mita <akinobu.mita@xxxxxxxxx>
> >> Cc: Jesse Gross <jesse@xxxxxxxxxx>
> >> Cc: Venkat Venkatsubra <venkat.x.venkatsubra@xxxxxxxxxx>
> >> Cc: Vlad Yasevich <vyasevich@xxxxxxxxx>
> >> Cc: Sridhar Samudrala <sri@xxxxxxxxxx>
> >> Cc: Neil Horman <nhorman@xxxxxxxxxxxxx>
> >> Cc: Steffen Klassert <steffen.klassert@xxxxxxxxxxx>
> >> Cc: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
> >> Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>
> >> Cc: linux-sctp@xxxxxxxxxxxxxxx
> >> Cc: dev@xxxxxxxxxxxxxxx
> >> Cc: netdev@xxxxxxxxxxxxxxx
> >> ---
> >>  include/net/red.h         | 2 +-
> >>  net/802/garp.c            | 2 +-
> >>  net/openvswitch/actions.c | 2 +-
> >>  net/rds/bind.c            | 2 +-
> >>  net/sctp/socket.c         | 2 +-
> >>  net/xfrm/xfrm_state.c     | 2 +-
> >>  6 files changed, 6 insertions(+), 6 deletions(-)
> >>
> > I'm largely indifferent to this patch, but I kind of feel like its just churn.
> > Whats the real advantage in making this change?  I grant that it clearly
> > indicates the type of random number generator we're using at a given call site,
> > But for those using net_random, you probably don't care too much about
> > the source of your random bits.  If you did really want true random vs.
> > pseudo-random data, you need to explicitly use the right call.  You're previous
> > patch series did good cleanup on differentiating the different random calls, but
> > this just seems like its removing what is otherwise useful indirection.
> 
> I overlooked the importance of  net_random() indirection.
> Thanks for the feedback. I'll leave all net_random() callers as-is in
> the next version.
Well, I guess I should qualify my opinion.  I find it useful personally (the
generation of nonces in many cases can be left to most any pseudo random
generator that the system deems is a 'good enough' balance between a fast
generator that doesn't block on low entropy and a reasonably secure one that
doesn't allow for easy prediction.  As those needs and factors change, its nice
to have a set point to change them at.  If you (or anyone else has a differing
opinion, I'm happy to listen to it.


Regards
Neil

> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/