On 19 Mar 2015, at 09:35, Antti Kantee wrote:
>
> 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 col
On Tue, 2015-03-17 at 15:15 +, Anthony PERARD wrote:
> On Tue, Mar 17, 2015 at 02:29:07PM +, 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
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:
-
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
Hello,
Wei Liu, le Tue 17 Mar 2015 14:29:07 +, a écrit :
> One of my lessons learned from the existing stubdom stuffs is that I
> should work with upstream and produce maintainable code.
Not only maintainable, but really make sure to have the time to stick
with upstream on the long run, first
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 Mar 2015, at 20:23, Antti Kantee wrote:
>
> 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",
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
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
On 18 Mar 2015, at 11:20, Martin Lucina wrote:
>>
>> A bit background information. A stubdom is a service domain. With QEMU
>> stubdom we are able to run QEMU device emulation code in a separate
>> domain so that bugs in QEMU don't affect Dom0 (the controlling domain).
>> Xen currently has a QEM
On Wed, 2015-03-18 at 12:45 +, Stefano Stabellini wrote:
> On Wed, 18 Mar 2015, Ian Campbell wrote:
> > On Wed, 2015-03-18 at 12:24 +0100, Martin Lucina wrote:
> > > ian.campb...@citrix.com said:
> > > > On Tue, 2015-03-17 at 15:27 +, Wei Liu wrote:
> > > > > This looks most interesting as
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 Wed, 18 Mar 2015, Ian Campbell wrote:
> On Wed, 2015-03-18 at 12:24 +0100, Martin Lucina wrote:
> > 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
On Wed, 2015-03-18 at 12:24 +0100, Martin Lucina wrote:
> 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
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
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 Tue, 2015-03-17 at 14:29 +, Wei Liu wrote:
> 2. The ability to access files in Dom0. That will be used to write to /
>read from QEMU state file.
This requirement is not as broad as you make it sound.
All which is really required is the ability to slurp in or write out a
blob of bytes t
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/misc/channel.txt
Ian.
On Tue, 17 Mar 2015, Anthony PERARD wrote:
> On Tue, Mar 17, 2015 at 02:29:07PM +, 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 ac
On Tue, Mar 17, 2015 at 03:15:17PM +, Anthony PERARD wrote:
> On Tue, Mar 17, 2015 at 02:29:07PM +, 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.
> >
> >
On Tue, 2015-03-17 at 14:57 +, Wei Liu wrote:
> On Tue, Mar 17, 2015 at 02:54:09PM +, Ian Campbell wrote:
> > On Tue, 2015-03-17 at 14:29 +, Wei Liu wrote:
> > > 2. The ability to access files in Dom0. That will be used to write to /
> > >read from QEMU state file.
> >
> > This req
On Tue, Mar 17, 2015 at 02:29:07PM +, 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
>wi
On Tue, Mar 17, 2015 at 02:54:09PM +, Ian Campbell wrote:
> On Tue, 2015-03-17 at 14:29 +, Wei Liu wrote:
> > 2. The ability to access files in Dom0. That will be used to write to /
> >read from QEMU state file.
>
> This requirement is not as broad as you make it sound.
>
Yes. You're
25 matches
Mail list logo
