Re: [MirageOS-devel] adding serializers to mirage tcpip

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 12 Jul 2014, at 01:21, Nik Sultana <ns441@xxxxxxxxx> wrote:

> Hwanju and I worked through adding two functions to different structures in 
> mirage-tcpip tonight:

[adding mirageos-devel to this]

> 
>  val get : () -> string
>  val set : string -> ()
> 
> where get collects state information from the structure and returns a string, 
> while set overwrites state information.
> 
> We tried basing this on adding "with sexp" (i.e., s-expression 
> (de)serialisation) to the state datatype in pcb.ml, and the datatypes it 
> refers to.
> 
> This ran into two difficulties. First, we encountered the Set module, from 
> OCaml's standard library. This was easily fixed by copying the module's 
> source code and adding "with sexp" to its types. The second problem was more 
> serious: we hit Lwt_mvar.t. The trick used for Set is harder to pull off 
> here, since we cannot just override a single class, but need to revise a 
> library.

If possible, you want to avoid forking libaries to add serializers.  The way 
that the `with sexp` syntax extension works is that it examines the AST of the 
type definition, and generates two function bodies that inductively add the 
relevant serialisers from the type definition itself.

These look like:

# type t = { a:int } with sexp;;
type t = { a : int; }                                                           
                                                                                
                  val t_of_sexp : Sexplib.Type.t -> t = <fun>                   
                                                                                
                                    val sexp_of_t : t -> Sexplib.Type.t = <fun> 
 

You can also just define these manually, which is how you deal with packages 
that don't define their sexp initializers.  So in the case of Lwt_mvar, don't 
fork Lwt -- think about what the stable serialization and deserialization of 
this should be.

For TCP, it's probably just to create a fresh mvar (although really, we should 
just refactor the TCP stack to eliminate the mvars -- Balraj and I are 
unconvinced that they should ever have been put in there in the first place).

> 
> I tried forking Lwt (from https://github.com/ocsigen/lwt ) but it was not 
> smooth to build on OSX. The configuration script claims that it cannot find 
> pthreads. I might have run into the bug described at 
> https://github.com/ocaml/opam/issues/1236. I reinstalled OCaml as instructed 
> there, but this didn't fix the problem. An alternative would be to downgrade 
> XCode, but I'm reluctant to do this. So, currently I cannot build Lwt 
> natively. If the patches you described in the earlier email are viable, 
> perhaps we could branch off them?

Any time you have a build failure, if you don't include the failing logs it's 
basically impossible to give any useful advice.  One workflow that may be 
helpful with the system compiler is:

$ opam switch -A system lwt-dev
$ eval `opam config env`
$ git clone git://github.com/ocsigen/lwt
$ opam pin lwt lwt/
$ opam install lwt

This will (in a fresh switch) give you an lwt development build, and the logs 
from that failure (if it still fails) will help pinpoint the issue.  Build 
failures for that should go up on https://github.com/ocsigen/lwt/issues and 
you'll probably get a swift answer from the maintainers, since OSX is a popular 
platform (I'll take a look too).

cheers,
Anil


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel