On Tue, Dec 25, 2012 at 08:47:26PM +0900, Akinobu Mita wrote: > 2012/12/25 Neil Horman <nhor...@tuxdriver.com>: > > 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.m...@gmail.com> > >> Cc: Jesse Gross <je...@nicira.com> > >> Cc: Venkat Venkatsubra <venkat.x.venkatsu...@oracle.com> > >> Cc: Vlad Yasevich <vyasev...@gmail.com> > >> Cc: Sridhar Samudrala <s...@us.ibm.com> > >> Cc: Neil Horman <nhor...@tuxdriver.com> > >> Cc: Steffen Klassert <steffen.klass...@secunet.com> > >> Cc: Herbert Xu <herb...@gondor.apana.org.au> > >> Cc: "David S. Miller" <da...@davemloft.net> > >> Cc: linux-s...@vger.kernel.org > >> Cc: d...@openvswitch.org > >> Cc: net...@vger.kernel.org > >> --- > >> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
