This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] [PATCH V4] libxl: make libxl communicate with xenstored

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?


Xen-devel mailing list