On 20/07/14 11:47, Justin Cormack wrote:
>> As a mid-term hack, might just make the implementation always read from
>> /dev/urandom and return some sensible amount of data.
>
> Attached is a suggested draft patch (only patrially tested) that
> defaults to arc4random or /dev/urandom, but can be overridden,
> supports a max read length, removes the flaky srand stuff, and shares
> all the code between the standard and fiber implementations.

What is the benefit of using arc4random?  Why not just use urandom on 
all platforms all the time?

I recognize the problem you are trying to solve, but I'm not convinced 
that adding switches and configuration variables is the right way -- it 
almost never is.  For one, I think we are at least morally obliged to 
keep supporting all sorts of configuration switches and variables we 
introduce.  Also, RUMP_FOO makes me think they apply to _all_ platforms, 
not just userspace.  As a general note, we should make it obvious if a 
parameter applies to rump kernels on any platforms, or is platform specific.

Again, I'd use the part from your patch where /dev/urandom is used, and 
strip out the rest.  _If_ some actual problems appear from the use of 
/dev/urandom, we can try to apply band-aid and bubblegum.  But, really, 
should try to fix the issue properly by looking at the NetBSD kernel 
side of the code, and thinking how to best make it cope with 
short-lived, multi-instance virtual environments.  Only if the result of 
that investigation is that it's not possible, would I be happy with 
configuration toggles.

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
rumpkernel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rumpkernel-users

Reply via email to