Not very friendly (well - that's relative), but it's pretty clear and provides a code reference that any developer can understand and check.
I was thinking of how the chip's output could possibly be used to attempt to predict the output of the PRNG and so be used in something like a side-channel attack. I'm not thinking it's highly likely, but with an organization of mathematicians and code breakers like the NSA has I wondered how much an advantage that would give against random keys, key exchanges, etc.
When I read about the issue, I was little concerned but did not follow trough. It seems that the whole issue started from people who don't know what they they are talking and who did not check facts. More and more people join and take the SOME approach of enjoying the discussion but not doing the work. This causes FUD and is bad thing. People who do this should be burned just like Linus did.
Btw. Using XOR to mix two random streams is textbook correct way to do it. It's simple and correct .
However, I found this message a good explanation of what RdRand is/does and how they're integrating it with /dev/random. http://www.spinics.net/lists/linux-crypto/msg05883.html
https://en.wikipedia.org/wiki/One-time_pad
Worst case (say, a string of 0s) you don't add any entropy to the pool. But you can't actually remove entropy with a simple xor. Again, that's assuming there are no other weaknesses in the linux PRNG.
The guy behind /dev/random is Ted Ts'o who has worked as Kerberos V5 project leader is part of security area directorate in IETF and chair of IPSec working group.
As far as I see /dev/random uses the best practices and don't innovate unnecessarily. If somebody is willing to spend time actually vetting the implementation, that would be great.