Re: [Xen-devel] some thoughts on appstacks and app-tools

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2014-07-15 at 17:28 +0100, Ian Jackson wrote:
> > >> extra =
> > >>     "builtin_ifconfig xenif0 create
> > >>     builtin_ifconfig xenif0 <address>
> > >
> > > I think this information is already available via xenstore.
> > 
> > Ok, but we still need to execute the actual configuration commands somehow.
> 
> If that isn't happening already if you specify "ip=..." in the
> appropriate place in the xl domain config file then there is a bug in
> something, I think.

Hrm, I think it is debatable whether guests should be using this IP
field.

The current/intend use is to propagate it to xenstore so the vif hotplug
scripts can use it to configure the host firewall if necessary.

I was about to say "we suck, this thing isn't documented anywhere"[0],
but actually the xenstore field is in the *backend* directory so I think
it would be wrong for the frontend to use it by default. (but either way
it still ought to be documented!)

The way one would do this today e.g. for NFS root or something would be
with a kernel command line option (e.g. ip=w.x.y.z for Linux, don't know
about rump or BSD)

Ian.

[0] docs/misc/xenstore-paths.markdown, xen/include/public/io/netif.h or
docs/man/xl.cfg.pod.5.

> 
> > >>     builtin_mount ffs /blk1 /etc
> > >
> > > We could perhaps provide a mount point in xenstore along with the
> > > rest of the pv block device control plane info.
> > 
> > I have no idea what that means.
> > 
> > Can you elaborate on how that will solve the practical problem of 
> > "thttpd needs some files in /etc"?
> 
> I mean that the domain config file could say
>   disk = [ "vdev=xvda, mountpoint=/etc, target=/path/to/blah.ffs" ]
> and libxl would put the mountpoint info in xenstore so something
> in the rump kernel Xen environment would pick it up.
> 
> > > This notion of having multiple processes is quite alarming.  There
> > > obviously won't be any memory protection between them, but also: how
> > > will their symbol namespaces be separated ?  Is it intended that they
> > > would be able to communicate via some kind of IPC (eg pipes or AF_UNIX
> > > sockets) ?
> > 
> > Symbol separation is what I referred to with crunchgen/busybox.  I don't 
> > know about busybox, but at least crunchen does symbol renaming/hiding.
> 
> Busybox is a single application, not a build tool.  I wasn't aware of
> crunchgen.  That does sound like it could do the job.
> 
> > Without going into a lot of detail, a rump kernel has an internal notion 
> > of a "process", sans a virtual memory space.  I think the original use 
> > case was debugging the AF_UNIX file descriptor passing code (though 
> > there are other uses now).  Multiple "processes" can communicate e.g. 
> > with pipes just like on a regular system.
> 
> Cor.  OK then.
> 
> > > Clearly applications can't background themselves (whatever that means)
> > > because they can't call fork().
> > 
> > My definition of backgrounding here = "rc script" doesn't wait for the 
> > current process to finish before running the next one.  That works quite 
> > easily, we just create a thread before we call the application main and 
> > either join that thread or not.  It might be possible to reach the same 
> > effect by "guessing" what fork() means for an application, but then 
> > again it might be better to not guess.
> 
> I think it would be better to do this ad-hoc in the script language.
> 
> > > Of course I appreciate that some of the xenstore-based answers I give
> > > above are perhaps less useful to other platforms, but perhaps they
> > > have something equivalent ?
> > 
> > They don't exist, so I don't know yet ;)
> > 
> > What I do know is that I'd like things to be general enough so that 
> > whatever infra you build on top of this doesn't have to be changed in 3 
> > weeks (or forked) when we discover a platform where there is no equivalent.
> 
> Yes.
> 
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel