Dead on/dev/random

During the FOTA differential upgrade, there was a retouch_binaries operation. I got stuck when I got here, and the waiting circle could not be completed in a few days. Later, I found that it was all done. Find a patch to solve the problem and change/dev/random to/dev/urandom.

diff --git a/updater/install.c b/updater/install.cindex a1acdb9..2f2631a 100644--- a/updater/install.c+++ b/updater/install.c@@ -450,7 +450,7 @@ Value* RetouchBinariesFn(const char* name, State* state,     bool override_set = false;     int32_t random_base = time(NULL) % 1024;     // some more randomness from /dev/random-    FILE *f_random = fopen("/dev/random", "rb");+    FILE *f_random = fopen("/dev/urandom", "rb");     uint16_t random_bits = 0;     if (f_random != NULL) {         fread(&random_bits, 2, 1, f_random);

When such a thing happens, of course it is first surfing the internet to search/dev/random and/dev/urandom, find a paragraph (http://www.linuxidc.com/Linux/2012-05/60476.htm)

The random numbers in Linux can be generated from two special files:/dev/urandom and/dev/random. Their principle of generating random numbers is to use the entropy pool of the current system to calculate a fixed number of random bits and then return these BITs as byte streams. The entropy pool is the environmental noise of the current system. Entropy refers to the degree of chaos of a system. system noise can be evaluated by many parameters, such as memory usage and file usage, the number of processes of different types. If the current environment noise is not very violent or the current environment noise is very small, for example, when the system is started, a large number of random bits are required, the random number generated at this time is not very good.

This is why there are two different files:/dev/urandom and/dev/random. The latter will block the program when new random numbers cannot be generated, and the former will not (ublock ), of course, the random number is not very good, which is not a good choice for applications such as encryption and decryption. /Dev/random will block the current program and will not be returned until a new random byte is generated based on the entropy pool, therefore, using/dev/random is slower than using/dev/urandom to generate a large number of random numbers.

Well, we will not go into details about the entropy above. I will study it later. But I can basically explain two of my questions:

1. Why is it so slow? "/Dev/random" is slow. During the upgrade, the system is basically very small. So many changes are used to generate random numbers? Even if I try to execute "cat/dev/random | OD-X" on my computer and then wait for it to output characters, it is also a turtle speed.
2. Why is it faster? Both the buttons and the touch screen will lead to changes in the mobile phone system. This change is the root cause of the random number. When the random number is reached, the update will continue. This is the reason why the system is still in a static state.

It's so slow.

Extended reading http://zh.wikipedia.org/wiki//dev/random