Re: [MirageOS-devel] Thoughts on the STACKV4 interface

[Nicolas Ojeda Bar <no263@xxxxxxxxxxxxxxx>]

Hi all,

You can now find an ongoing implementation of this proposal in the
following branches:

- https://github.com/nojb/mirage#remove-stackv4
- https://github.com/nojb/mirage-tcpip#remove-stackv4

Summary of important changes:

- (mirage-types) Made IP a submodule of UDP/TCP
- (mirage) Add configuration support for Ipv6
- (mirage) Use phantom type variable to enable polymorphic use of Ipv4/Ipv6
- (mirage) Removed NETSTACK (previously STACKV4)
- (mirage-tcpip) Add support to register callbacks to Ethif, Ipv4,
Ipv6, Udp, Tcp
- (mirage-tcpip) Removed NETSTACK (previously STACKV4).
- (mirage-tcpip) Made Ip a submodule of Udp and Tcp.
- (mirage) Generate code to make network devices listen after `connect`

Pending:

* (mirage) When in DIRECT mode, generate a call to Netif.listen (which
starts the whole stack) at the end of `main.ml`
- (mirage) Generate code to set up ARP
- (mirage) Generate code to configure DHCP

I was very happy to be able to set it up so that one can use Ipv4/Ipv6
polymorphically: for example,
the old `direct_udp` combinator now has type
```
val direct_udp : 'a ip impl -> 'a udp impl
```
which is supposed to be applied to one of the two available implementations
```
val create_ipv4 : ... -> v4 ip impl
val create_ipv6 : ... -> v6 ip impl
```
This let us require udp/ipv4 (type `v4 udp typ`) or udp/v6 (type `v6
udp typ`) in a signature if needed or we can work with a generic
udp/ip (type `'a udp typ`) if the precise ip version is not important.

Any comments, suggestions, etc. appreciated!

Cheers,
Nicolas


On Tue, Nov 25, 2014 at 11:12 AM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> I'm merging Nicolas' patches into my trees at the moment to 'assess the 
> damage' about renaming STACKV4, and:
>
> - so far it's remarkably contained (to places that explicitly use it, like 
> Dns and Conduit -- Cohttp compiles without modification)
>
> - I'm in complete agreement about high level APIs.
>
> As a checkpoint, I'm going to merge the IPv6 patches into HEAD repositories, 
> and then think through the implications of completely changing STACKV4.
>
> -anil
>
>> On 25 Nov 2014, at 10:51, Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx> 
>> wrote:
>>
>> +1
>>
>> (my only caveat being that removing STACK will require updating many many 
>> code samples etc, so this might take a while to merge. but i am generally in 
>> favour of making the apis more uniform, and of having a good high-level api.)
>>
>> On 25 Nov 2014, at 10:41, Nicolas Ojeda Bar <no263@xxxxxxxxxxxxxxx> wrote:
>>
>>> Hi list,
>>>
>>> TL;DR- With the addition of IPv6 the interface V1.STACKV4 (renamed
>>> NETSTACK) looks like an overgrown garden of weed and grass. I propose
>>> (see below) to completely eliminate this interface and to shift its
>>> role to the existing Udp & Tcp signatures/implementations.
>>>
>>> Right now STACKV4 performs two roles:
>>>
>>> 1) Keeps track of open ports for Tcp & Udp
>>> 2) Connects together the whole stack of TCP/UDP over IP, ARP over
>>> ETHIF over NETIF.
>>>
>>> Remarks:
>>>
>>> - 1) this can be done independently for Tcp and Udp and there doesn't
>>> seem to be a problem keeping the `port -> callback` table in those
>>> modules directly.
>>>
>>> - 2) boils down to calling `Ethif.input`, `Ipv{4,6}.input` with
>>> arguments specifying the callbacks for each protocol.  With the
>>> current signatures one needs to have all the callback functions "at
>>> once".  It is not possible to register, say, the `tcp` callback
>>> independently of the `udp` callback or the `ipv4` callback
>>> independently of the `ipv6` one.  But this is easily solved by making
>>> the implementations keep a table `protocol -> callback` and exposing a
>>> function in the signatures to register such a callback.
>>>
>>> - STACKV4 is neither a good low-level nor a good high-level
>>> abstraction to the network stack.  We should let the existing
>>> ETHIF/IP/TCP/UDP provide a low-level interface and start thinking how
>>> to make a good high-level interface (maybe in the style of `launchd`
>>> or `systemd`) to all network services (and maybe other Mirage
>>> services?) that hides these modules.
>>>
>>> If we make the above changes then there is no more a raison d'etre for
>>> STACKV4 and we can eliminate it altogether.  The current unikernels
>>> that depend on stackv4 will instead depend on a subset of {udp,tcp} x
>>> {ipv4,ipv6}. Instead of having a DIRECT/SOCKET network stack we would
>>> have DIRECT/SOCKET UDP & TCP implementations.
>>>
>>> Thoughts ?
>>>
>>> Cheers,
>>> Nicolas
>>>
>>> _______________________________________________
>>> MirageOS-devel mailing list
>>> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>>
>>
>> --
>> Cheers,
>>
>> R.
>>
>>
>>
>>
>> _______________________________________________
>> MirageOS-devel mailing list
>> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>

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