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

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

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