On Friday, 24.07.2015 at 17:01, Ian Jackson wrote:
> Martin Lucina writes ("[PATCH v3] xenconsole: Ensure exclusive access to
> console using locks"):
> > If more than one instance of xenconsole is run against the same DOMID
> > then each instance will only get so
/libxl_internal.c:libxl__lock_domain_userdata().
Signed-off-by: Martin Lucina
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
.gitignore | 1 +
tools/console/Makefile | 6 -
tools/console/client/main.c | 55 +
3 files changed, 61
/libxl_internal.c:libxl__lock_domain_userdata().
Signed-off-by: Martin Lucina
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
.gitignore | 1 +
tools/console/Makefile | 5 -
tools/console/client/main.c | 53 +
3 files changed, 58
On Friday, 24.07.2015 at 14:32, Ian Jackson wrote:
> > +static void console_lock(int domid)
> > +{
> > + lockfile = malloc(PATH_MAX);
> > + if (lockfile == NULL)
> > + err(ENOMEM, "malloc");
> > + snprintf(lockfile, PATH_MAX - 1, "%s/xenconsole.%d", XEN_LOCK_DIR,
> > domid);
>
> W
On Friday, 24.07.2015 at 14:11, Ian Campbell wrote:
> I'm afraid this (delving into another components private headers) isn't
> allowed. Instead you should add the two lines to tools/console/Makefile
> to generate a local _paths.h:
>
> genpath-target = $(call buildmakevars2header,_paths.h)
> $(eva
If more than one instance of xenconsole is run against the same DOMID
then each instance will only get some data. This change ensures
exclusive access to the console by creating and obtaining an exclusive
lock on /xenconsole..
Signed-off-by: Martin Lucina
Cc: Ian Jackson
Cc: Stefano Stabellini
On Thursday, 23.07.2015 at 16:23, Ian Campbell wrote:
> On Thu, 2015-07-23 at 17:09 +0200, Martin Lucina wrote:
>
> > > But maybe it would be better to set max_fd = -1 on declaration and
> > > do
> > > the max dance here as with the following cases?
> &g
attributes.
Existing behaviour when xenconsole is run from a terminal does not
change.
This allows for non-interactive use, eg. running "xl create -c" under
systemd or piping the output of "xl console" to another command.
Signed-off-by: Martin Lucina
Cc: Ian Jackson
Cc: St
On Thursday, 23.07.2015 at 09:48, Ian Campbell wrote:
> On Wed, 2015-07-22 at 19:08 +0200, Martin Lucina wrote:
> > If xenconsole is run with stdin closed or redirected to /dev/null,
> > console_loop() will return immediately due to failure to read from
> > STDIN_FILENO. This
attributes.
Existing behaviour when xenconsole is run from a terminal does not
change.
This allows for non-interactive use, eg. running "xl create -c" under
systemd or piping the output of "xl console" to another command.
Signed-off-by: Martin Lucina
Cc: Ian Jackson
Cc: St
po...@iki.fi said:
> Where do you propose to inject that faking out (and what does it
> even mean)? Someone at Berkeley decided that socket drivers should
> be globally enumerated, and PF_UNIX leads to exactly one handler.
> Just hacking hooks as local patches into the PF_UNIX driver is
> against
a...@recoil.org said:
> > Point 2. will further require implementing support in the Rump Kernel,
> > either for a shim which would proxy AF_UNIX / AF_INET transparently using
> > vchan, or possibly later implementing a separate socket family (AF_VCHAN /
> > AF_HYPER?). Once that is done you should
ian.campb...@citrix.com said:
> On Tue, 2015-03-17 at 15:27 +, Wei Liu wrote:
> > This looks most interesting as it implies we can easily pipe a console
> > to it.
>
> BTW, rather than rawe consoles we should probably consider using the
> channel extension: http://xenbits.xen.org/docs/unstable
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 might be enough for what you need.
>
>
(Adding some of the Mirage folks to Cc:)
wei.l...@citrix.com said:
> Hi all
>
> I'm now working on upstream QEMU stubdom, and rump kernel seems to be a
> good fit for this purpose.
>
> A bit background information. A stubdom is a service domain. With QEMU
> stubdom we are able to run QEMU devic
ian.campb...@citrix.com said:
> On Wed, 2015-02-04 at 12:21 +0100, Martin Lucina wrote:
> > Caused by:
> >
> > > commit 3b36d1f55a08e1849ccd5424afb0fbe29647bd6c
> > > Author: Martin Lucina
> > > Date: Mon Feb 2 18:00:36 2015 +0100
> > >
&g
Caused by:
> commit 3b36d1f55a08e1849ccd5424afb0fbe29647bd6c
> Author: Martin Lucina
> Date: Mon Feb 2 18:00:36 2015 +0100
>
> Remove even older rumpxen-app-* variants of app-tools
>
> Signed-off-by: Martin Lucina
bash: line 14:
/home/osstest/bu
a...@recoil.org said:
> On 26 Jan 2015, at 17:42, Martin Lucina wrote:
> >
> > tal...@gmail.com said:
> >> In case it's useful: for the standalone version of Mini-OS used by
> >> Mirage, I had to include these directories too:
> >>
> >>
tal...@gmail.com said:
> In case it's useful: for the standalone version of Mini-OS used by
> Mirage, I had to include these directories too:
>
> 1. xen/include/public
> 2. xen/common/libfdt
> 3. xen/include/xen/libfdt
> 4. config
>
> ( https://github.com/talex5/xen/tree/minios-releases )
Ah, so
mar...@lucina.net said:
> > The build was this
> >
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/33416/build-amd64-rumpuserxen/info.html
> > and the output files are here:
> >
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/33416/build-amd64-rumpuserxen/build/
> > of which the rel
ian.jack...@eu.citrix.com said:
> Martin Lucina writes ("Re: [Xen-devel] [rumpuserxen test] 33416: regressions
> - FAIL"):
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/33416/test-amd64-amd64-rumpuserxen-amd64/guest-rump-console
>
> Yes.
>
> > -
ian.jack...@eu.citrix.com said:
> flight 33416 rumpuserxen real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/33416/
>
> Regressions :-(
I presume this is the console log:
http://www.chiark.greenend.org.uk/~xensrcts/logs/33416/test-amd64-amd64-rumpuserxen-amd64/guest-rump-console
--
samuel.thiba...@ens-lyon.org said:
> > From: Martin Lucina
> > Date: Thu, 4 Dec 2014 14:33:53 +0100
> > Subject: [PATCH] Mini-OS: netfront: Fix rx ring starvation in network_rx
> >
> > In network_rx() we must push the same amount of requests back onto the
>
mar...@lucina.net said:
> Rather, shouldn't the final if() in the loop (where data is sent up) be:
>
> if(rx->status > NETIF_RSP_NULL) { ... }
>
> *we can't use NETIF_RSP_OKAY as NETIF_RSP_NULL is defined to be 1 (yuck).
>
> I don't see any value in keeping the printk(), the netfront driver al
xplicit using #ifdef HAVE_LIBC
- take it out of the for() loop initialisation and condition
- set some = 1 and use break to exit the loop
I've done this in the updated patch, take a look and let me know what you
think.
Martin
>From 3880f59159bf0a05b47b6e723091b1e7e4fb6814 Mon Sep 17
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 Mini-OS duplicates what we would
need to
andrew.coop...@citrix.com said:
> I think this is a very good idea, and I am completely in favour of it.
>
> 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 lik
Hi,
In rumprun-xen [1] we use Mini-OS as a "base firmware" layer in our stack.
Currently we are using a slightly bastardized fork of the xen.git Mini-OS.
We would like to avoid this turning into a permanent fork. Following
previous discussion [2] on and openmirage-devel I would like to coordinate
t push the same amount of requests back onto the
ring in the second loop that we consumed in the first loop. Otherwise
the ring will eventually starve itself of free request slots and no
packets will be delivered.
Signed-off-by: Martin Lucina
---
extras/mini-os/netfront.c | 17 ---
ian.jack...@eu.citrix.com said:
> I wonder if this mechanism could be used for some or all of the things
> that you're currently using xenstore for. Specifying which virtual
> block devices to mount where, or what network configuration to use,
> are things that other rump kernel runners would want
po...@iki.fi said:
> 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.
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 update the existing downloadable
> > 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.
Running "xr" with no parameters
(Cc-ing xen-devel as this is relevant to general use of
"application-specific" domains, MirageOS, etc.)
Hi,
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 impleme
34 matches
Mail list logo
