New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] simplify random #551

Merged
merged 3 commits into from Oct 2, 2016

Conversation

Projects
None yet
4 participants
@hannesm
Member

hannesm commented Jun 29, 2016

this is only the interface change -- after discussion I'll adapt the mirage tool to do the magic.

  • in contrast to common believe, there is no need for random to have blocking behaviour
  • helper functions which generate your favourite number representation here between bounds will be done in a helper library (no need to convolute the interface with it)
  • my current plan is to have two implementations: OCaml's Random and nocrypto's fortuna. if anywhere in your dependency chain you have nocrypto already, that one is used as default_random (the logic for this is already in the mirage tool). you can always explicitly pass the lagged-Fiobnacci PRNG (seeded with /dev/urandom or gettimeofday etc. -- fine for MirageOS on Unix, brittle on Xen (esp. on ARM where there is no wall clock)) to your modules instead of the default_random. Initialisation of any PRNG is done via its connect function (as atm for nocrypto, but not for Random).

@hannesm hannesm changed the title from [RFC] simplify random device to [RFC] simplify random Jun 29, 2016

@yomimono

This comment has been minimized.

Member

yomimono commented Jul 8, 2016

This seems like a reasonable change to me, including the implementation plan in your comment.

@yomimono yomimono referenced this pull request Jul 27, 2016

Closed

pending items for consideration for Mirage 3.0 #571

9 of 9 tasks complete

@yomimono yomimono added this to the mirage 3.0.0 milestone Sep 15, 2016

hannesm added some commits Jun 29, 2016

rename default_random to stdlib_random
implementation thereof is provided by the mirage-stdlib-random package

@hannesm hannesm force-pushed the hannesm:rondom branch from d0d654a to 540c881 Sep 30, 2016

@hannesm

This comment has been minimized.

Member

hannesm commented Sep 30, 2016

The first parts are done in here:

I don't know of other users of the V1.RANDOM interface:

There are still some libraries (tcpip tests, ocaml-dns, ipaddr) which manually use Random.self_init () and thus the stdlib Random by default (some of which - such as ocaml-dns protocol.ml - are not inside of a mirage application). Comments on how to deal with that is welcome.

Also, maybe @Drup has some advice how to get "either nocrypto or stdlib random" bound, depending on whether the unikernel already depends on nocrypto (sth to fill in here: let direct_tcp ?(clock=default_monotonic_clock) ?(random=stdlib_random) ?(time=default_time) ip = tcp_direct_func () $ ip $ time $ clock $ random) -- there's still some (trivial) boilerplate missing for a nocrypto_random_conf, similar to stdlib_random_conf.

@avsm

This comment has been minimized.

Member

avsm commented Sep 30, 2016

Should randomconv use ocaml-integers for the int16/etc types?

@hannesm

This comment has been minimized.

Member

hannesm commented Sep 30, 2016

it predates ocaml-integers, and as mentioned in ocamllabs/ocaml-integers#2 randomconv shouldn't need to depend on ocaml-integers.

@avsm

This comment has been minimized.

Member

avsm commented Sep 30, 2016

Makes sense!

@hannesm

This comment has been minimized.

Member

hannesm commented Sep 30, 2016

and there's 548ce90 the nocrypto rng for your pleasure....

@yallop

This comment has been minimized.

Member

yallop commented Sep 30, 2016

randomconv shouldn't need to depend on ocaml-integers.

That's true if you're using standard types (int, int32, int64), or very small types (uint8, uint16), but it's not true in other cases (uint32, uint64, and platform-specific types).

@hannesm

This comment has been minimized.

Member

hannesm commented Sep 30, 2016

(and before we start to functorize all the code, maybe we should realise that a sensible OS will always have a single RNG, a single TIME, a single PCLOCK, and a single MCLOCK -- and there's no need to functorize all the libraries over these resources -- see https://github.com/pqwy/mirage-os-shim/ on how we'd get there)

@hannesm

This comment has been minimized.

Member

hannesm commented Sep 30, 2016

@hannesm

This comment has been minimized.

Member

hannesm commented Oct 2, 2016

Travis is happy (in mirage-skeleton over here)
changes:

@yomimono yomimono merged commit d440fd6 into mirage:master Oct 2, 2016

1 check failed

continuous-integration/travis-ci/pr The Travis CI build failed
Details

@hannesm hannesm deleted the hannesm:rondom branch Oct 2, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment