RE: [Xen-devel] [PATCH V4] libxl: make libxl communicate with xenstored by socket or xenbus driver

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Fri, 2010-09-17 at 16:06 +0100, Ian Jackson wrote:
> Ian Campbell writes ("RE: [Xen-devel] [PATCH V4] libxl: make libxl 
> communicate with xenstored by socket or xenbus driver"):
> > On Thu, 2010-09-16 at 20:21 +0100, Jun Zhu (Intern) wrote:
> > > The functions, such as dm_xenstore_record_pid, do not have a ctx
> > > pointer in its function parameters. In these functions, if they invoke
> > > the libxl__xs_open, it does not have ctx pointer. Should we use the
> > > extern ctx directly? I find only the functions in xl_cmdimpl.c use ctx
> > > in this way, and the other functions under libxl get the ctx pointer
> > > from its function parameter.  
> > 
> > Under no circumstances should libxl try and use a global ctx pointer
> > from the application using libxl.
> > 
> > dm_xenstore_record_pid runs in a new process and therefore there is no
> > existing context which can be used.
> 
> I think it is fine to to reuse the ctx from the caller in
> dm_xenstore_record_pid.  Your "new process" test seems to imply
> problems for any other daemonic processes libxl may need to spawn.

Hmm, It's not actually the same context any more since the fork but
perhaps that doesn't really matter.

I would have thought that reusing ctx->xsh over a fork would cause all
manner of mayhem but it looks like libxl_fork cleverly takes care of
that for us.

I'd similarly concerned about any other fds linked to the context, are
any fds used by the particular xentoollog_logger implementation used by
the context going to be alright for example?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel