Breaking API: Remove cstruct

[palainp]

Dear devs,
Continuing the Cstruct-free work, this is a first proposal for mirage-net.
As it's a breaking change, please let me know what is your preferred API shape :)
This PR is conservative in respect with the current allocations situation, but this can be changed to allow upper layers to allocate buffers, and let write/listen read from/write to them.
Best.

[hannesm]

Dear @palainp, thanks for this PR. I have two minor suggestions, but totally agree that this is the right path forward.

[hannesm]

sorry, I had two commits that were part of the last release (4.0.0) on my laptop, which weren't pushed... so I just pushed them, shouldn't affect this PR much... but implementations of this interface may be affected.

[palainp]

Yes, thanks! I think I'm now up to date, and I'll need to adapt a bit mirage-net-solo5 :)

[hannesm]

I'd be keen to wait here until next week and then merge and release this as the next major version. This way we can avoid having too many pinned repositories required. Maybe a heads up mail to the mirageos-devel mailing list would be worth for such a large change!?

[palainp]

Or maybe we can try to break even more the API:

  val write: t -> off:int -> len:int -> string -> (unit, error) result Lwt.t
  val listen: t -> off:int -> len:int -> bytes -> (unit, error) result Lwt.t

I'm not sure about the names, for example with the write implementations, the callback result is compared to the size argument, and now we have to trust it. Similarly for listen where header_size is now an offset to write the result to, and we have to trust it. As @hannesm pointed out, this boundary checking problem may be now more something about trusting the lower part will work correctly and users will never change that?

[palainp]

And with that change, the allocation need to be done in the upper layers. 👻

[hannesm]

The issue/reason for write having a callback where you can modify the data is that the network interface should be able to decide which buffer you can write to. As example, the mirage-net-xen implementation uses page-aligned memory, and for it to not need to copy/blit any data from the above layers, it passes the buffer to the client.

Now, that may be wishful thinking, since bytes isn't the kind of memory mirage-net-xen can use (it needs non-moving memory since that memory region is passed to the other xen domain, and only when the other says "ok, can be freed" the memory can be reclaimed). [that's at least how I understand it] -- this also means that we need to copy in any case.

[hannesm]

I think we'll need to play around with the different APIs and figure what is convenient to use, and what has a reasonable performance. I suspect that if every layer allocates their own data (so, ethernet allocates 14 bytes, ip another 20, ...) and on the write the mirage-net implementation needs to allocate a big buffer and blit everything together, this may suffer from performance issues.

On the other hand, it is worth to try, esp. if we're using string/bytes and not cstruct/bigarray (where allocation is expensive).