On Wednesday, 13.11.2024 at 12:43, Hannes Mehnert wrote:
> - since solo5 lacks a bit maintenance, also performance (unikraft has
> batch IO), maybe some day also multicore
FWIW, my plan for Solo5 was to consider using Muen's SHMStream V2 for
IPC across the tender <-> binding boundary:
https://g
Dear friends and colleagues,
effective today, I am stepping down from both maintaining Solo5 and from the
core team of MirageOS.
- What does that mean?
I will no longer monitor pull requests or issues filed on repositories in
the Solo5/ or mirage/ organisations on GitHub, with the exception of t
Hans,
On Thursday, 05.11.2020 at 16:05, Martin Lucina wrote:
> thanks for investigating! I've created an issue to track this, though I
> don't expect to have time to look into it soon:
>
> https://github.com/Solo5/solo5/issues/483
>
> Hans, you might want to subscrib
Ricardo,
> > Was able to reproduce it and now have a better idea of what's going on
> > (with a temporary fix included). The issue happens when using qemu with a
> > boot disk image exposed as a virtio-blk device. The problem is that solo5
> > tries to configure a virtio device that was already in
Dear all,
We are pleased to announce the release of MirageOS 3.9.0.
Our last release announcement was for [MirageOS
3.6.0](https://mirage.io/blog/announcing-mirage-36-release), so we will
also cover changes since 3.7.x and 3.8.x in this announcement.
New features:
- The Xen backend has been [re
(Re-sending with a current email for Ricardo)
On Monday, 26.10.2020 at 11:37, Martin Lucina wrote:
> Hi,
>
> On Sunday, 25.10.2020 at 13:37, Hans Ole Rafaelsen wrote:
> > Hi,
> >
> > I have been investigating some more, and I seem to be a 'virtio-block
>
Hi,
On Sunday, 25.10.2020 at 13:37, Hans Ole Rafaelsen wrote:
> Hi,
>
> I have been investigating some more, and I seem to be a 'virtio-block
> device' problem. On the OpenStack cloud this device is reported when Solo5
> boots, but not on my local installation.
>
> I changed from IDE (default) t
Hi Hans,
On Saturday, 24.10.2020 at 23:11, Hans Ole Rafaelsen wrote:
> Hi Hannes, Romain and Martin,
>
> Thanks for your replays. I think I have a better understanding now.
>
> My goal is to get a small application running on a OpenStack qemu/kvm
> cloud. I have posted in a previous post about p
Hi Hans,
others have already replied with instructions. Just to clarify the
higher-level concepts:
On Saturday, 24.10.2020 at 08:33, Hans Ole Rafaelsen wrote:
> Hi,
>
> When reading the MirageOS tutorials/documentation it seems like virtio
> target has some limitations. E.g. only one network in
Hi Hans,
On Sunday, 11.10.2020 at 19:55, Hans Ole Rafaelsen wrote:
> Hi,
>
> I'm trying to run some of the tutorial examples on OpenStack. This is a
> "Nokia AirFrame Cloud Infrastructure" with "OpenStack Compute version
> 17.0.7-1"
Any idea what QEMU version that uses internally?
>
> I have b
Hello,
over the past couple of months we have developed a new Xen platform stack [1]
for MirageOS, replacing our use of Mini-OS for the low-level C startup and
interfaces to Xen, and aligning the entire stack with our existing
Solo5-based backends as much as is practical.
The implementation is no
On 2020-06-22 18:20, Jan Beulich wrote:
On 22.06.2020 18:09, Roger Pau Monné wrote:
On Mon, Jun 22, 2020 at 05:31:00PM +0200, Martin Lucina wrote:
On 2020-06-22 15:58, Roger Pau Monné wrote:
On Mon, Jun 22, 2020 at 12:58:37PM +0200, Martin Lucina wrote:
Aha! Thank you for pointing this out
On 2020-06-22 15:58, Roger Pau Monné wrote:
On Mon, Jun 22, 2020 at 12:58:37PM +0200, Martin Lucina wrote:
Aha! Thank you for pointing this out. I think you may be right, but
this
should be possible without doing the demuxing in interrupt context.
If you don't do the demuxing i
On 2020-06-19 19:42, Roger Pau Monné wrote:
On Fri, Jun 19, 2020 at 06:54:26PM +0200, Roger Pau Monné wrote:
On Fri, Jun 19, 2020 at 06:41:21PM +0200, Martin Lucina wrote:
> On 2020-06-19 13:21, Roger Pau Monné wrote:
> > On Fri, Jun 19, 2020 at 12:28:50PM +0200, Martin Lucina wrote:
On 2020-06-19 13:21, Andrew Cooper wrote:
On 19/06/2020 11:28, Martin Lucina wrote:
RIP 0x209997 is the 'hlt' instruction in
mirage_xen_evtchn_block_domain() so we are indeed blocking waiting for
events to show up.
I can't find this in the code, but it might be an x86-ism
On 2020-06-19 13:21, Roger Pau Monné wrote:
On Fri, Jun 19, 2020 at 12:28:50PM +0200, Martin Lucina wrote:
On 2020-06-18 13:46, Roger Pau Monné wrote:
> On Thu, Jun 18, 2020 at 12:13:30PM +0200, Martin Lucina wrote:
> > At this point I don't really have a clear idea of h
On 2020-06-18 13:46, Roger Pau Monné wrote:
On Thu, Jun 18, 2020 at 12:13:30PM +0200, Martin Lucina wrote:
At this point I don't really have a clear idea of how to progress,
comparing my implementation side-by-side with the original PV
Mini-OS-based
implementation doesn't s
On 2020-06-19 01:43, Andrew Cooper wrote:
On 18/06/2020 11:13, Martin Lucina wrote:
On Monday, 15.06.2020 at 17:58, Andrew Cooper wrote:
On 15/06/2020 15:25, Martin Lucina wrote:
Hi,
puzzle time: In my continuing explorations of the PVHv2 ABIs for the
new MirageOS Xen stack, I've run
On Monday, 15.06.2020 at 17:58, Andrew Cooper wrote:
> On 15/06/2020 15:25, Martin Lucina wrote:
> > Hi,
> >
> > puzzle time: In my continuing explorations of the PVHv2 ABIs for the
> > new MirageOS Xen stack, I've run into some issues with what looks like
> >
On 2020-06-15 17:03, Roger Pau Monné wrote:
This way of event channel injection is slitgly hackish, and I would
recommend using HVMOP_set_evtchn_upcall_vector, that way vectors will
be properly routed using the lapic.
Using HVM_PARAM_CALLBACK_TYPE_VECTOR vectors are injected without
setting the
Hi,
puzzle time: In my continuing explorations of the PVHv2 ABIs for the new
MirageOS Xen stack, I've run into some issues with what looks like
missed deliveries of events on event channels.
While a simple unikernel that only uses the Xen console and effectively
does for (1..5) { printf("foo
On Wednesday, 10.06.2020 at 15:21, Andrew Cooper wrote:
> > I don't need v2 at all, I was just going by the comments in grant_table.h,
> > which read: "Version 1 of the grant table entry structure is maintained
> > purely for backwards compatibility. New guests should use version 2."
>
> Ha...
>
On Wednesday, 10.06.2020 at 14:40, Andrew Cooper wrote:
> > So, going with the grant v2 ABI, is there a modern equivalent of
> > GNTTABOP_get_status_frames? Reading memory.h I'm guessing that it might be
> > XENMEM_add_to_physmap with space=XENMAPSPACE_grant_table and
> > idx=(XENMAPIDX_grant_table
On Tuesday, 09.06.2020 at 11:22, Andrew Cooper wrote:
> There is a little bit of history here...
>
> GNTTABOP_setup_table was the original PV way of doing things (specify
> size as an input, get a list of frames as an output to map), and
> XENMAPSPACE_grant_table was the original HVM way of doing
Hi,
I've been making progress on bootstrapping a new, PVHv2 only, Xen platform
stack for MirageOS [1]. The basics are now functional and I have started to
re-implement the grant table code.
After studying both the Mini-OS and Linux implementations some, I don't
understand the difference between u
On Wednesday, 27.05.2020 at 16:41, Roger Pau Monné wrote:
> > > > If I make this simple change:
> > > >
> > > > --- a/bindings/xen/boot.S
> > > > +++ b/bindings/xen/boot.S
> > > > @@ -32,7 +32,7 @@
> > > > #define ENTRY(x) .text; .globl x; .type x,%function; x:
> > > > #define END(x) .size x,
On Tuesday, 26.05.2020 at 18:30, Roger Pau Monné wrote:
> > Turns out that the .note.solo5.xen section as defined in boot.S was not
> > marked allocatable, and that was doing that was confusing our
> > linker script[1] (?).
>
> Hm, I would have said there was no need to load notes into memory, an
Oh! I think I've found a solution, even though I don't entirely understand the
problem/root cause:
On Tuesday, 26.05.2020 at 12:12, Martin Lucina wrote:
> > On Tue, May 26, 2020 at 11:34:21AM +0200, Roger Pau Monné wrote:
> > Forgot to ask, but can you also add the
On Tuesday, 26.05.2020 at 13:42, Andrew Cooper wrote:
> On 26/05/2020 13:41, Martin Lucina wrote:
> > On Tuesday, 26.05.2020 at 12:58, Andrew Cooper wrote:
> >> On 26/05/2020 12:54, Martin Lucina wrote:
> >>> On Tuesday, 26.05.2020 at 11:58, Andrew Cooper wrote:
>
On Tuesday, 26.05.2020 at 12:58, Andrew Cooper wrote:
> On 26/05/2020 12:54, Martin Lucina wrote:
> > On Tuesday, 26.05.2020 at 11:58, Andrew Cooper wrote:
> >> On 26/05/2020 09:52, Martin Lucina wrote:
> >>> On Monday, 25.05.2020 at 17:59, Andrew Cooper wrote:
>
On Tuesday, 26.05.2020 at 11:58, Andrew Cooper wrote:
> On 26/05/2020 09:52, Martin Lucina wrote:
> > On Monday, 25.05.2020 at 17:59, Andrew Cooper wrote:
> >> On 25/05/2020 17:42, Jürgen Groß wrote:
> >>> You need to setup virtual addressing and enable 64 bit mode
On Tuesday, 26.05.2020 at 12:03, Roger Pau Monné wrote:
> On Tue, May 26, 2020 at 11:34:21AM +0200, Roger Pau Monné wrote:
> > On Tue, May 26, 2020 at 10:52:21AM +0200, Martin Lucina wrote:
> > > On Monday, 25.05.2020 at 17:59, Andrew Cooper wrote:
> > > > On 25/05
On Tuesday, 26.05.2020 at 11:34, Roger Pau Monné wrote:
> On Tue, May 26, 2020 at 10:52:21AM +0200, Martin Lucina wrote:
> > On Monday, 25.05.2020 at 17:59, Andrew Cooper wrote:
> > > On 25/05/2020 17:42, Jürgen Groß wrote:
> > > > You need to setup virtual addressing
On Monday, 25.05.2020 at 17:59, Andrew Cooper wrote:
> On 25/05/2020 17:42, Jürgen Groß wrote:
> > You need to setup virtual addressing and enable 64 bit mode before using
> > 64-bit GDT.
> >
> > See Mini-OS source arch/x86/x86_hvm.S
>
> Or
> https://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen
On Monday, 25.05.2020 at 18:41, Andrew Cooper wrote:
> On 25/05/2020 17:04, Martin Lucina wrote:
> > Hi,
> >
> > I'm trying to bootstrap a new PVH-only Xen domU OS "from scratch", to
> > replace our existing use of Mini-OS for the early boot/low-level sup
Hi,
I'm trying to bootstrap a new PVH-only Xen domU OS "from scratch", to
replace our existing use of Mini-OS for the early boot/low-level support
layer in MirageOS. I've done this by creating new Xen bindings for Solo5
[1], basing them on our existing virtio code [2].
Unfortunately, I can't seem
Hello,
On Tuesday, 08.10.2019 at 00:01, Hugues Fafard wrote:
> What I've done in the 'solo5' repository:
> [...]
>
> What I've done in the 'mirage-solo5' repository:
> [...]
> What I've done in the 'mirage-gpio' repository:
> [...]
> What I've done in the 'mirage-gpio-solo5' repository:
> [...]
Dear all,
We are pleased to announce the release of MirageOS 3.6.0. This release
updates MirageOS to support Solo5 [1] 0.6.0 and later.
New features:
* Support for the Solo5 `spt` (sandboxed process tender) target via `mirage
configure -t spt`. The `spt` target runs MirageOS unikernels in a mi
On Friday, 27.09.2019 at 09:20, Anil Madhavapeddy wrote:
> Martin Lucina can comment on Solo5 issues — there has just been a big release
> with multiple device support, so trying out network bridging or building a
> Solo5 RAID for block devices might be of interest given the newnes
Hi all,
On Wednesday, 30.01.2019 at 20:03, Martin Lucina wrote:
> If you're at FOSDEM, hope to see you there. For those not attending, I'll
> follow up with links to the recording after the event.
A recording of the talk is now available at the event page:
https://fosdem.org/201
Hi all,
Ricardo Koller and myself will be presenting a talk on Solo5 at FOSDEM,
this coming Sunday (Feb 3rd).
From the abstract:
Solo5 is a microkernel friendly, sandboxed, re-targetable execution
environment for unikernels, with a taste for minimalism. We will start
with an overview
On Monday, 29.10.2018 at 10:26, Anil Madhavapeddy wrote:
> On 29 Oct 2018, at 10:16, Andrew J wrote:
> >
> > Hi,
> >
> > I'm starting a project with mirage to build a protocol server. I'm
> > wondering if there is any way to use dune to handle the configuring and
> > building since it can do tes
Hi all,
I'm happy to announce that our ACM SoCC 2018 paper entitled "Unikernels as
Processes" is now publicly available at
https://dl.acm.org/citation.cfm?id=3267845.
The paper by Dan and Ricardo of IBM Research, Nikhil of BITS Pilani and
myself presents the central tenet that the host attack sur
Hi Adam,
On Thursday, 13.09.2018 at 07:07, Adam Steen wrote:
> Hi All
>
> As some of you know i have been working at making MirageOS work on OpenBSD,
> It now works, I have built and tested all applications, device-usage and
> tutorials in mirage-skeleton.
This is good news! Thanks very much f
All,
progress update on this:
After spending a couple of days writing a bunch of OPAM-repository-munging
tools, so that I never again have to do 20+ changes to packages manually,
I've finally done an end-to-end test of the changes with Mirage, using my
wip-renaming branch of the opam-solo5 reposi
On Tuesday, 04.09.2018 at 12:40, Adam Steen wrote:
> Hi
>
> i was trying to test static_website_tls and got the following error after a
> "mirage configure -t ukvm && gmake depends"
>
>
> [ERROR] The sources of the following couldn't be obtained, aborting:
> - gmp-freestanding.6.1.2-1
On Monday, 27.08.2018 at 18:00, Hannes Mehnert wrote:
> hey,
>
> On 27/08/2018 16:38, Martin Lucina wrote:
> > On Friday, 24.08.2018 at 19:05, Hannes Mehnert wrote:
> >> sounds about right!
> >
> > Your reply did not go to the list, adding it back in Cc:.
>
On Friday, 24.08.2018 at 19:05, Hannes Mehnert wrote:
> sounds about right!
Your reply did not go to the list, adding it back in Cc:.
> On 24/08/2018 16:57, Martin Lucina wrote:
> > Therefore, the new dependencies would look like this:
> >
> > mirage-solo5: Depends on s
Hi all,
as part of the renaming and restructuring of Solo5 to adopt better
terminology and allow for expansion to other (non-VT) targets [1], [2], I'd
like to rename the Solo5 OPAM packages.
Currently, the dependency tree is as follows:
mirage-solo5: Depends on solo5-kernel-ukvm | solo5-kernel-v
On Thursday, 17.05.2018 at 00:11, Thomas Gazagnaire wrote:
> What happened to http://canopy.mirage.io/Projects ? Would it be possible to
> restart/fix it or move the project list somewhere else?
Nothing, but I had to restart the dom0 hosting http://canopy.mirage.io/
yesterday and now the unikerne
Dear all,
Some time ago I conducted an informal poll amongst the top Solo5
contributors about whether to set up a mailing list or other forum
dedicated to general Solo5 development discussion, or to (ab)use the
MirageOS mailing list for this. The results were overwhelmingly in favour
of setting up
Hi Adam,
On Monday, 02.04.2018 at 07:15, Adam Steen wrote:
> Hi
>
> another opam install.
>
> when i do the following
>
> "opam pin add mirage-solo5 https://github.com/mirage/mirage-solo5.git";
>
> i get
>
> [NOTE] mirage-solo5 is currently git-pinned to
> https://github.com/adamsteen/mira
On Sunday, 11.03.2018 at 16:15, Justin Cinkelj wrote:
> Any hint what is the cause?
> Complete example is at
> https://github.com/justinc1/mirage-skeleton/tree/jc-crash-issue-251, commit
> 1da971caae5295d47588b6dc9637e68e2b0c7f89.
Thanks for the report; I've replied on Github and in a previous thr
On Monday, 05.02.2018 at 10:04, JIM Yuan wrote:
> Just an update on this.
>
> I tried to run this on Ubuntu 14.04 with Xen 4.4. It works :)
This looks like the exact same issue as that described by Vittorio in
https://github.com/mirage/mirage-skeleton/issues/251 and now also confirmed
by a 3rd pe
Hi all,
I've created a new repository in the mirage organisation,
"mirage-propaganda". This is intended for storing things like a visual
identity, logos, t-shirt designs and so on. I've seeded it with a bare
README and a CC-BY-SA-4.0 license.
T-shirt designs for the ongoing Marrakesh hackathons w
Folks,
as some of you know, various breaking changes in Mirage/Solo5 (both from an
API/ABI and user point of view) have been in the pipeline for some time
now.
In order to unblock these changes and progress Mirage/Solo5 development
towards a new release, as of today, I have:
1. Added upstream bo
On Friday, 17.11.2017 at 10:19, Mindy Preston wrote:
> On 11/17/17 07:14, Hannes Mehnert wrote:
>
> > Dear people,
> >
> > the current state:
> > - MirageOS3 was advertised as "working with OCaml 4.03 upwards"
> > - mirage-xen works as of now only with 4.04.2
> > - OCaml 4.06 was released with a
On Tuesday, 18.04.2017 at 12:38, Mindy wrote:
> Hi Michael,
>
> I notice that you're passing this argument:
>
> --ipv4 10.128.0.0/20
>
> but the internal IP for your instance is 10.128.0.3 . You might instead try
> --ipv4 10.128.0.3/20 .
>
> Failing that, configuring with a higher log level mi
Hi Guillaume,
On Wednesday, 25.01.2017 at 09:11, Guillaume wrote:
> After reading more articles about Docker and MirageOS I think that
> what I missed is the fact that docker is used to provide an
> environment for building Unikernels, not to run them. I'm a little
> confused so any informations a
On Friday, 02.12.2016 at 13:50, Drup wrote:
> >>I am generally ok with that workflow which improves the current one. I am
> >>just a bit concerned by the number of intermediate steps and the
> >>proliferation of subcommands that you need to remember. Can we try to merge
> >>some of these command
On Thursday, 01.12.2016 at 09:19, Thomas Gazagnaire wrote:
> > - mirage configure should recompile the configuration
> > according to
> > - mirage build should build, and error out if the unikernel was not
> > configured upfront
>
> How do you work with multiple target/config in parallel with th
On Thursday, 01.12.2016 at 19:10, Drup wrote:
>
> >I'm now wondering: what was the rationale for having `mirage describe`
> >vs `mirage help` at all?
> >Maybe it would be better to incorporate the tty-output options of
> >`describe` into the `help` output, and have `mirage describe` only
> >produc
On Wednesday, 30.11.2016 at 06:20, Mindy wrote:
> On November 30, 2016 5:44:42 AM CST, Martin Lucina wrote:
> >On Wednesday, 30.11.2016 at 11:35, Richard Mortier wrote:
> >> On 30 November 2016 at 11:32, Martin Lucina
> >wrote:
> >> > On Wednesday, 30.11.
On Wednesday, 30.11.2016 at 11:35, Richard Mortier wrote:
> On 30 November 2016 at 11:32, Martin Lucina wrote:
> > On Wednesday, 30.11.2016 at 11:25, Richard Mortier wrote:
> >> I thought one of the things `mirage describe` could do was display
> >> information a
On Wednesday, 30.11.2016 at 11:25, Richard Mortier wrote:
> I thought one of the things `mirage describe` could do was display
> information about possible configuration options -- ie., it's useful
> to *not* have to run `mirage configure` first and actually set those
> options explicitly?
Isn't t
On Monday, 28.11.2016 at 15:14, Hannes Mehnert wrote:
> On 25/11/2016 18:26, Hannes Mehnert wrote:
> > It does not yet work completely (clean seems to be broken), but please
> > provide feedback on https://github.com/mirage/functoria/pull/84 and
> > https://github.com/mirage/mirage/pull/703
>
> Up
On Tuesday, 22.11.2016 at 08:56, Mindy wrote:
> https://github.com/Solo5/solo5/issues/82 - a tracking issue for the solo5
> components of the MirageOS 3.0.0 release (all of which are completed! well
> done, mato, djwillia, ricarkol, hannesm, and anyone I've missed)
Unfortunately I had to unchec
On Monday, 14.11.2016 at 12:48, Daniel Bünzli wrote:
> On Monday 14 November 2016 at 12:22, Hannes Mehnert wrote:
> > What is the problem of putting it into share/pkgconfig? Why is this 'no
> > other solution'?
>
> As people have pointed out this is semantically incorrect. The proper
> solution
On Friday, 14.10.2016 at 11:29, Anil Madhavapeddy wrote:
> Good news everyone! The experimental documentation repository at
> http://docs.mirage.io now builds again, and has been refreshed to the latest
> set of libraries assembled from the MirageOS3 dev remote at
> https://github.com/mirage/mir
Hi,
I'm trying to do something like this in mirage/mirage.ml:
let get_ld target =
Cmd.read
"PKG_CONFIG_PATH=$(opam config var lib)/lib/pkgconfig solo5-kernel-%s
--variable=ld" target >>| fun output ->
output
i.e. execute the shell command and return the output.
How should I use the "R
On Thursday, 01.09.2016 at 10:05, Hannes Mehnert wrote:
> On 31/08/2016 17:31, Mindy wrote:
> > Having just tripped over something available in 4.03 but not 4.02
>
> is this significant enough to drop 4.02 support (or is it only the
> Hashtbl.filter_map_inplace)?
>
> Since most MirageOS applicati
Hannes,
On Tuesday, 19.07.2016 at 18:04, Hannes Mehnert wrote:
> This is the general plan (see also
> https://github.com/mirage/mirage-platform/issues/124). It would IMHO be
> nice if this would be done within the 3.0 release cycle, just to be able
> to declare simple and clean constraints (confl
Hi all,
the mirage-solo5 package (i.e. the Solo5 "platform bindings") currently
bundle C stubs for unrelated packages which get linked into a
libsolo5camlbindings.a.
Based on some discussion on Slack and also ongoing in a PR Mindy pointed me
to (https://github.com/mirage/io-page/pull/34), is the
Hi folks,
I'm happy to report that Mirage/Solo5 is coming along nicely. For those not
familiar with the port, Mirage/Solo5 enables MirageOS to run on KVM and
other virtio-compliant hypervisors (testers welcome!).
While not quite ready for prime time yet, several people have asked for
instructions
On Friday, 20.05.2016 at 09:10, Hannes Mehnert wrote:
> >> The rationale behind this structure is threefold:
> >>
> >> 1) It has explicit contracts defining which interfaces each layer
> >> provides/depends on. Further, by not providing a separate "posix" package,
> >> we discourage adding more C c
Hi,
Together with Dan Williams we're working on getting the Mirage/Solo5
bindings into mergeable state. Part of this process is figuring out what
the structure for mirage-solo5 (the "platform bindings") and its
dependencies should be.
The current structure of mirage-platform for Xen (the only non
Hi folks,
forwarding this, useful for anyone debugging either Mirage/Rumprun or
Mirage/Solo5 under KVM/QEMU. For Solo5, you'll want to replace 'x86_boot'
symbol with the equivalent 64-bit startup function.
Cheers
Martin
- Forwarded message from Martin Lucina -
Date: T
On Monday, 04.01.2016 at 12:27, Anil Madhavapeddy wrote:
> On 4 Jan 2016, at 12:15, Martin Lucina wrote:
> >
> > If I have a Mirage/Rumprun hybrid unikernel (whether using -k or not,
> > irrelevant) and I would like Rumprun to mount some block devices, but
> > Mirage
All,
FYI for those who'd like an easy way to try the in-progress Mirage on
Rumprun a.k.a. Mirump port:
- Forwarded message from Martin Lucina -
Date: Fri, 6 Nov 2015 16:16:10 +0100
From: Martin Lucina
To: rumpkernel-us...@freelists.org
Cc: Richard Mortier , a...@recoil.org
Su
On Saturday, 20.06.2015 at 11:57, Thomas Leonard wrote:
> On 15 June 2015 at 11:56, Martin Lucina wrote:
> > On Friday, 12.06.2015 at 16:40, Thomas Leonard wrote:
> >> I also tested mirage-skeleton/console, which worked but ran rather
> >> fast (it's suppos
On Friday, 12.06.2015 at 16:40, Thomas Leonard wrote:
> I also tested mirage-skeleton/console, which worked but ran rather
> fast (it's supposed to wait 1s between each print). Calling
> gettimeofday showed the clock running fast for some reason.
I've logged issues rumprun/#30 (clock runs fast) an
Hi all,
I'm happy to announce that the MirageOS cross-port to rumprun has
progressed to the point where it can now serve HTTP.
Detailed instructions for building "MiRump" unikernels can be found in the
README in my opam-rumprun repository:
https://github.com/mato/opam-rumprun
Obligatory screen
Hi all,
what do I need to do to be able to run the static_website_tls example from
the mirage-dev branch of mirage-skeleton?
It dies for me with "Tls.Config: invalid configuration: certificate type or
usage does not match".
I don't understand where it is getting the certificate from -- there's
n
On Thursday, 11.06.2015 at 15:11, Thomas Gazagnaire wrote:
> > Is it possible that I have a version mismatch where the version of conduit
> > (0.8.4) is incompatible with mirage-http (2.2.0)?
>
> indeed.
>
> conduit 0.8.4 works with mirage-http 2.3.0 (cohttp 0.17.*) and mirage-http
> 2.4.0 (coht
On Thursday, 11.06.2015 at 10:18, Anil Madhavapeddy wrote:
> On 11 Jun 2015, at 10:11, Thomas Gazagnaire wrote:
> >
> >> Is it possible that I have a version mismatch where the version of conduit
> >> (0.8.4) is incompatible with mirage-http (2.2.0)?
> >
> > indeed.
> >
> > conduit 0.8.4 works
Hi all,
I've been steadily adding more packages to my opam-rumprun repository [1]
as I fix cross-compilation issues in the various build systems.
As of today, I'm *this close* to getting the TLS and HTTP stack to build on
rumprun. However, I've run into an error I don't understand.
While buildin
On Friday, 22.05.2015 at 16:17, Antti Kantee wrote:
> On 22/05/15 15:35, Martin Lucina wrote:
> >Hi all,
> >
> >in the spirit of "announce early and often", I now have a working OCaml
> >cross compiler toolchain building unikernels with the rumprun stack[1
Hi all,
in the spirit of "announce early and often", I now have a working OCaml
cross compiler toolchain building unikernels with the rumprun stack[1], and
basic support for Mirage OS working.
Here's a screenshot for proof of the mir-console example from
mirage-skeleton running on KVM:
http://ib
On Wednesday, 20.05.2015 at 12:02, Martin Lucina wrote:
> Getting further through the list of Mirage dependencies, trying to get
> sexplib building for rumprun hits another different problem with OASIS:
*facepalm* Ok, sorry, this was caused by a two-character typo:
["ocaml
On Tuesday, 19.05.2015 at 15:58, Martin Lucina wrote:
> > >E: Failure("Expected built file '_build/src/unix/dlllwt-unix_stubs.so'
> > >doesn't exist.")
> > >
> > >This is expected; the rumprun toolchain does not support dynamic
>
On Tuesday, 19.05.2015 at 16:48, Daniel Bünzli wrote:
> Le mardi, 19 mai 2015 à 16:44, Martin Lucina a écrit :
> > What I don't understand is why
> > upstream OCaml 4.02.01 claims to support cross-compilation but doesn't; was
> > this original effort abandoned by u
On Tuesday, 19.05.2015 at 16:12, Martin Lucina wrote:
> In theory PR#6266
> (https://github.com/ocaml/ocaml/commit/c1e26ad14aec62cefe3d5fb24cf8702caa39db2b)
> might fix these options to let me run OCaml configure directly against the
> rumprun cross compiler but I've not tri
On Tuesday, 19.05.2015 at 17:15, Peter Zotov wrote:
> On 2015-05-19 16:58, Martin Lucina wrote:
> >This begs the question, why did you use the approach of building the
> >cross-compiler as a normal OPAM package, rather than as a compiler
> >package?
>
> Because the cr
Hi Thomas,
On Tuesday, 19.05.2015 at 12:49, Thomas Gazagnaire wrote:
> Lwt's discover.ml is unfortunately known to be very ad hoc and often breaks
> so I am not very surprised. Usually patches to fix it sent upstream are
> kindly accepted (until someone be brave enough to completely rewrite that
On Tuesday, 19.05.2015 at 14:09, Peter Zotov wrote:
> >What can be done to fix the above? Should I be using a host
> >compiler built
> >and installed by OPAM rather than the system compiler
> >(4.02.1-1ppa3~precise
> >on Debian wheezy). [I'll try this and see if it helps...]
>
> No. This is an iss
[Re-sending with correct opam-devel address]
Hi all,
I'm working on getting OCaml and Mirage OS running on top of the rumprun
unikernel stack[1].
Rumprun provides a unikernel stack with a POSIXy (NetBSD-HEAD) userspace
and can run on Xen, QEMU/KVM, bare metal and POSIX userspace. The
resulting
Hi all,
I'm working on getting OCaml and Mirage OS running on top of the rumprun
unikernel stack[1].
Rumprun provides a unikernel stack with a POSIXy (NetBSD-HEAD) userspace
and can run on Xen, QEMU/KVM, bare metal and POSIX userspace. The
resulting Mirage + rumprun unikernel will thus be able t
Hi all,
I'm pleased to announce that we have a working httpd + FastCGI + PHP
stack running on Xen, powered by a Rump Kernel -based Unikernel:
http://thread.gmane.org/gmane.comp.rumpkernel.user/709
Our setup works with no significant modifications to the existing PHP or
httpd codebases; I believe
98 matches
Mail list logo
