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-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
