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
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 sound
s like
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
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 a
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 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
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
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
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
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
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
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
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
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.
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
17 matches
Mail list logo
