Hi, Wolfgang
Thanks for the reply.
On 9/16/2015 2:37 PM, Wolfgang Denk wrote:
Dear Josh Wu,
In message 1442373526-842-1-git-send-email-josh.wu@atmel.com you wrote:
As 'time(0) | getpid()' sometimes get same value. That depends on the value of getpid().
I think removing some "random input" from the way how we compute the seed is a bad idea.
So that is not a expected behavior. We expect different value for the seed when when run it in many times.
What is your execution environment? In any sane OS it is higly unlikely that you will see the same or even similar PIDs for successive runs of the program - each run will start a new process, which will get a new PID.
my system is Ubuntu 14.04
#uname -a Linux melon 3.13.0-45-generic #74-Ubuntu SMP Tue Jan 13 19:36:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Following is my test history:
➜ tools date && ./gen_eth_addr Wed Sep 16 14:48:53 CST 2015 4a:c3:21:45:17:b2 ➜ tools date && ./gen_eth_addr Wed Sep 16 14:48:56 CST 2015 a6:29:4b:0b:e6:d0 ➜ tools date && ./gen_eth_addr Wed Sep 16 14:49:02 CST 2015 d2:41:66:54:64:aa ➜ tools date && ./gen_eth_addr Wed Sep 16 14:49:06 CST 2015 2a:58:1d:b0:f0:c5 ➜ tools date && ./gen_eth_addr Wed Sep 16 14:49:13 CST 2015 1e:8e:6f:0e:16:b8 ➜ tools date && ./gen_eth_addr Wed Sep 16 14:49:19 CST 2015 56:4f:58:67:ad:30 ➜ tools date && ./gen_eth_addr Wed Sep 16 14:49:21 CST 2015 2e:53:29:97:6a:8a ➜ tools date && ./gen_eth_addr Wed Sep 16 14:49:26 CST 2015 d2:41:66:54:64:aa ➜ tools date && ./gen_eth_addr Wed Sep 16 14:49:35 CST 2015 d2:41:66:54:64:aa
➜ tools date && ./gen_eth_addr Wed Sep 16 14:49:50 CST 2015 92:33:16:3f:0a:56 ➜ tools date && ./gen_eth_addr Wed Sep 16 14:49:58 CST 2015 92:33:16:3f:0a:56
In above commands, I have two duplicated eth addr: 92:33:16:3f:0a:56 d2:41:66:54:64:aa
[On a mostly idle Linux system (4.1.6 kernel) I see zero dupes in a set of 30,000 invocations of getpid().]
One can argue if ORing the values is the most clever idea, or if for example ADDing them would result in more "randomness".
Sure. The ORing seems has big chance to get same result in my machine.
But completely removing the pid() is bad - any parallel runs of the program on any machines with synchronized times would predictably result in the same seeds which is definitely worse behaviour than what we have now.
I understand your concern. My intention is make it harder to generate the duplicated result.
Maybe we can ORing the MSB of time(0)? I'll investigate it little more.
So this patch remove the getpid(), just use the time(0) as the seed.
NAK. This is a bad idea.
Best regards,
Wolfgang Denk
Best Regards, Josh Wu