Thomas Gleixner wrote:
On Mon, 13 Jun 2011, Jarod Wilson wrote:
Add a new function pointer to struct clocksource that can optionally be
filled in by clocksources deemed to be high enough resolution to feed
the random number generator entropy pool.
Uurrg.
+ * @entropy: random entropy pool addition function (optional, and
+ * requires a fairly high-resolution clocksource)
Why do you want to do that ? Looking at the implementations of TSC and
HPET it's the same code. We really do not want to add that all over
the place. We can make that a property flag and the entropy function
common to the core code.
+/**
+ * Do we have at least one clocksource that can generate entropy?
+ */
+bool clocksource_entropy_available(void)
+{
+ struct clocksource *src;
+ bool entropy_possible = false;
+
+ mutex_lock(&clocksource_mutex);
+ list_for_each_entry(src,&clocksource_list, list) {
+ if (src->entropy) {
+ entropy_possible = true;
+ break;
+ }
+ }
+ mutex_unlock(&clocksource_mutex);
+
+ return entropy_possible;
+}
+EXPORT_SYMBOL(clocksource_entropy_available);
That should be evaluated when clocksources are registered not at some
random point in time, which might return total nonsense as it's not
guaranteed that the clocksource which has the entropy property is
going to end up as the current clocksource.
+/**
+ * Call the clocksource's entropy-generation function, if set
+ */
+void clocksource_add_entropy(void)
+{
+ if (!curr_clocksource->entropy)
+ return;
Why restricting it to the current clocksource? We can use the best
registered one for this which has the entropy property set.
Yeah, John had some similar suggestions, and locally, I've got a
modified version that instead of adding entropy functions for each
clocksource, adds an entropy rating, then the highest rated entropy
clocksource gets used, but a common clocksource entropy function that
calls the chosen clocksource's read function. The entropy clocksource
function gets picked by way of another function similar to
clocksource_select, called in all the same places.
However, since none of this is going to be viable until the random code
is significantly restructured, I haven't bothered with posting any of
the updates I've made. I can toss the delta out there if anyone really
wants to take a look at it, but otherwise, I'll just sit on it until
said restructuring happens.
--
Jarod Wilson
ja...@redhat.com
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
