Ian,
Thank you for the explanations.
Hmm. (not replying to anything specific)
My guess is that shared libs won't be the biggest problem. I'd find it
extremely surprising if you can take a Linux (or any other !NetBSD)
packaging system and discover the dozens of dependencies of QEMU to not
c
On 08/09/15 16:15, Ian Campbell wrote:
On Tue, 2015-09-08 at 15:03 +, Antti Kantee wrote:
For unikernels, the rump kernel project provides Rumprun, which can
provide you with a near-full POSIX'y interface.
I'm not 100% clear: Does rumprun _build_ or _run_ the application? It so
Hi,
Wei Liu hinted that I should "chime in and / or provide corrections"
(his words). I'll attempt to do exactly that by not really replying to
anything specific. For the record, when I say "we" in this mail, I mean
"people who have contributed to the rump kernel project" (as also
indicated
On 10/06/15 16:15, Wei Liu wrote:
On Wed, Jun 10, 2015 at 05:01:27PM +0100, Ian Jackson wrote:
Ian Campbell writes ("[PATCH RFC 0/6+2+2] Begin to disentangle libxenctrl and
provide some stable libraries"):
[stuff]
Most of this looks good to me.
As part of this change I've begun to get rid
On 06/05/15 11:03, Stefano Stabellini wrote:
On Wed, 6 May 2015, Ian Jackson wrote:
Stefano Stabellini writes ("Re: [PATCH] OSSTEST: introduce a raisin build
test"):
That's fine as there is no hidden git cloning with raisin. All the trees
are specified explicitly in the config file.
Is this
On 02/05/15 03:00, osstest service user wrote:
flight 52955 rumpuserxen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/52955/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 5 rumpuserxen-build
On 16/04/15 10:23, Ian Campbell wrote:
But I think we can safely(?) say that work done on rumpkernel will be a
more worthwhile investment, while work on stubdom would be more of a
sunk cost...
I can't speak for "stubdom", but I sure hope that work done on rump
kernels is a worthwhile investmen
On 19/03/15 08:48, Martin Lucina wrote:
By "faking out" Anil means a shim to get existing applications
which currently use PF_UNIX (and possibly PF_INET, though that will be
harder to fake) to use the hypervisor bus to talk to another colocated
unikernel instead.
The motivations for this are:
-
On 18/03/15 21:21, Anil Madhavapeddy wrote:
This is not an argument for or against; if you want to expose AF_WHATEVER to
applications running on a rump kernel, you need to sell AF_WHATEVER to NetBSD,
not to rumpkernel-users. Well, preferably you need to sell it to everyone
implementing socket
On 18/03/15 19:05, Anil Madhavapeddy wrote:
This fits in with a couple of things I hope to make time to work on in the
next couple of months:
1. Introspection of Rump Kernel domUs for ops purposes, i.e. get some
basic "ps", "top", "vmstat"-like information about what the domU is
doing fr
On 18/03/15 11:22, Martin Lucina wrote:
po...@rumpkernel.org said:
etfs isn't a file system, e.g. it doesn't allow listing files or
removing them, but it does give you complete control of what happens
when data is read or written for /some/path. But based on the other
posts, sounds like it migh
On 17/03/15 14:29, Wei Liu wrote:
I've now successfully built QEMU upstream with rump kernel. However to
make it fully functional as a stubdom, there are some missing pieces to
be added in.
1. The ability to access QMP socket (a unix socket) from Dom0. That
will be used to issue command to Q
On 06/03/15 10:49, Ian Campbell wrote:
A new one to me:
+ cp 'rumpuserxen/rump-kernel*' dist/usr/local/lib/xen/rump-kernel
cp: cannot stat `rumpuserxen/rump-kernel*': No such file or directory
We think we figured out how to actually do things, and some
repo-reorganizing was mandated. The chu
On 15/02/15 18:51, xen.org wrote:
flight 34575 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34575/
Regressions :-(
This looks like a new failure:
=== snip ===
checking for ncurses.h... no
configure: error: Unable to find a suitable curses library
configure: error: .
On 05/02/15 15:51, Ian Jackson wrote:
It looks to be some sort of Heisenbug in the rump kernel stuff.
I agree. We had a failure on the 16th of January which looked like
some kind of race:
(Subject: Re: [Xen-devel] [rumpuserxen test] 33416: regressions - FAIL)
Aha! I told you I don't belie
On 04/02/15 14:33, Ian Jackson wrote:
Ian Campbell writes ("Re: [PATCH] ts-rumpuserxen-build: Use new app-tools"):
On Wed, 2015-02-04 at 12:36 +0100, Martin Lucina wrote:
Update to use the new app-tools names.
I'm not sure if we need to support bisection over this change -- but I
think we pro
On 16/01/15 11:17, Ian Jackson wrote:
The latter is the GPF turning out to be unreproducible.
I guess we should keep an eye out in case it turns out to be a race
rather than a cosmic ray.
I do not believe in cosmic rays.
Some notes in case it resurfaces:
1) the topmost caller address appears
On 07/12/14 18:09, Samuel Thibault wrote:
I said it unclearly. I meant the use of
#include (e.g. string.h, stdio.h, etc)
?
minios itself doesn't do this when it's not compiled with HAVE_LIBC.
Building with HAVE_LIBC is really not a requirement for using mini-os.
For rump projects, I would e
On 07/12/14 17:55, Samuel Thibault wrote:
Antti Kantee, le Thu 04 Dec 2014 22:52:05 +, a écrit :
Currently, the software stack in rumprun-xen is confusing
because MiniOS partially uses libc
Which part of libc? MiniOS itself is very independent of libc, it only
ships a couple of things. We
On 05/12/14 18:31, Martin Lucina wrote:
po...@iki.fi said:
I wonder if work is minimized if we attempt to merge before or after
we (I?) take the carving knife for a second round in the rumprun-xen
repo to minimize MiniOS to run only on top of itself.
Before, I think. Minimizing our copy of Min
On 04/12/14 14:40, Andrew Cooper wrote:
There are already-identified issues such as MiniOS leaking things like
ARRAY_SIZE() into linked namespaces, which I havn't yet had enough tuits
to fix.
I think splitting things like the stub libc away from the "MiniOS Xen
Framework" is also a good idea. I
On 13/11/14 18:57, Martin Lucina wrote:
Also, I'd prefer to call it 'stubetc' rather than 'etc' to make it clearer
that it's not supposed to be used as a normal /etc.
I'd prefer it to be completely hidden from the user. But sure, call it
stubetc for now.
This brings up another question; what
On 13/11/14 17:07, Martin Lucina wrote:
po...@iki.fi said:
Actually, hmm, there's already an image for /etc available. I
understood from irc discussion that you needed slight modifications to
passwd for mathopd. In case your changes don't conflict with what's
already up there, you could just u
On 13/11/14 15:46, Martin Lucina wrote:
Following is the high-level description from the Git commit:
Can you also post an example of the usage of your CLI tool? Actually,
can you post a rough description of the entire process that a user would
have to follow, i.e. compile, configure, run.
Ru
On 13/11/14 11:22, Martin Lucina wrote:
back in July there was some discussion on configuring rump kernel
application stacks:
http://thread.gmane.org/gmane.comp.rumpkernel.user/321
Some proposals were made, but no actual implementation work was done. In
the mean time, I have implemented the simp
25 matches
Mail list logo
