|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] auto configuring ip/netmask info
I've just released a minor point releases of mirage and tcpip that expose the IPV4 functor in STACKV4, so the low-level workarounds should no longer be needed. https://github.com/ocaml/opam-repository/pull/1973 (our fancy new changelog page will update shortly) -anil On 7 Mar 2014, at 10:56, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote: > Great -- upstreaming this to the libraries will requiring exposing a little > more configuration abstraction in STACKV4, so I'll leave this as a "raw > skeleton" for the moment. > > -anil > > On 5 Mar 2014, at 18:59, Julian Chesterfield <julian.chesterfield@xxxxxxxxx> > wrote: > >> To confirm - this worked correctly for me. I can pass in static params now >> and the VM picks them up correctly. Just FYI - build fails if htdocs >> directory is not first created. It might be sensible to add an htdocs dir >> with skeleton index.html content file for newbies. >> >> Thanks! >> - J >> >> On 4 Mar 2014, at 20:10, Anil Madhavapeddy wrote: >> >>> I pushed a sample unikernel that reads the kernel command line, as a quick >>> test to see if this will work for you Julian. Note that you must pass it >>> the right "extra" kernel args or it will just exit (I didn't bother with >>> error handling as it's just during startup). >>> >>> We don't expose a very flexible configuration interface through STACKV4 >>> yet, so this unikernel is written explicitly from Ethif upwards. It's >>> quite nice that we can do this if the library abstractions aren't >>> sufficient, if I do say so myself :-) >>> >>> https://github.com/mirage/mirage-skeleton/tree/master/xen/static_website%2Bip >>> >>> (note that this will only compile under Xen at the moment, not Unix) >>> >>> -anil >>> >>> On 26 Feb 2014, at 17:10, Julian Chesterfield >>> <julian.chesterfield@xxxxxxxxx> wrote: >>> >>>> I've opened a ticket for this discussion: >>>> >>>> https://github.com/mirage/mirage/issues/228 >>>> >>>> - J >>>> >>>> On 25 Feb 2014, at 20:40, Richard Mortier wrote: >>>> >>>>> >>>>> On 25 Feb 2014, at 17:09, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote: >>>>> >>>>>> Julian and I were looking into the various Xen config options for >>>>>> networking this morning, and it turns out that the XL/XM toolstacks can >>>>>> both specify a per-VIF ip/netmask/gateway directly in the VIF >>>>>> configuration. e.g. >>>>>> >>>>>> ``` >>>>>> vif = >>>>>> ['bridge=xenbr0,ip=10.0.0.2,netmask=255.255.255.0,gateway=10.0.0.1'] >>>>>> >>>>>> These are written into the VIF backend tree in xenstore. >>>>> >>>>> aha. i wondered about that. where's the best docs on xenstore -- it's >>>>> probably something i should know a bit more about. >>>>> >>>>>> I'd like to take advantage of this by having the network stack >>>>>> automatically probe for it and use it if available (i.e. a 'default' >>>>>> mode in the stack configuration, which can be overridden by the manual >>>>>> IP or DHCP options). >>>>>> >>>>>> Any thoughts on the best place to put it, though? The obvious place is >>>>>> in mirage-net-{unix/xen}, but we would need a Xenstore-equivalent for >>>>>> Unix (which has come up several times. Dave, how viable is it to have a >>>>>> simple Unix Xenstore that maps to a filesystem tree? We can project >>>>>> configuration variables into there for tuntap, and perhaps take care of >>>>>> bridge configuration at the same time as well. >>>>> >>>>> i can't comment on the viability of a unix equivalent, but that seems to >>>>> make a lot of sense to me. >>>>> >>>>>> Another backend that will need an equivalent registry-style interface >>>>>> are the kFreeBSD backend (which could call back into userspace via an >>>>>> ioctl interface). >>>>> >>>>> what would the js backend do? (or would the issue simply never arise?) >>>>> >>>>> -- >>>>> Cheers, >>>>> >>>>> R. >>>>> >>>>> >>>>> >>>>> >>>>> This message and any attachment are intended solely for the addressee and >>>>> may contain confidential information. If you have received this message >>>>> in error, please send it back to me, and immediately delete it. Please >>>>> do not use, copy or disclose the information contained in this message or >>>>> in any attachment. Any views or opinions expressed by the author of this >>>>> email do not necessarily reflect the views of the University of >>>>> Nottingham. >>>>> >>>>> This message has been checked for viruses but the contents of an >>>>> attachment >>>>> may still contain software viruses which could damage your computer >>>>> system, you are advised to perform your own checks. Email communications >>>>> with the University of Nottingham may be monitored as permitted by UK >>>>> legislation. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >> >> >> _______________________________________________ >> 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 > _______________________________________________ MirageOS-devel mailing list MirageOS-devel@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |