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 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.

Maybe libxl__xs_open could, as a special case, accept a NULL gc and not
log anything in that case? dm_xenstore_record_pid doesn't log failure
today anyway and I presume something in the parent process will
eventually log the failure to start the DM.

Otherwise I think the choices are:

1) Continue to treat dm_xenstore_record_pid as a special case which uses
xs_*_open directly.

2) Allocate a new context in dm_xenstore_record_pid using
libxl_ctx_init. It's not clear what the right logger to use for this
would be, maybe some sort of /dev/null logger, in which case we might as
well just add a special case to libxl__xs_open which doesn't log...

3) Rework libxl__spawn_spawn so that the intermediate callback (i.e.
dm_xenstore_record_pid) is called in the context of the parent, and
hence can have the parent's context passed to it. I don't know if this
is even possible given the requirements of libxl__spawn_spawn but it
might for example involve setting up a pipe to pass the pid from the
intermediate process back to the parent, or something along those lines.

3 might be a good thing to do anyway but it's likely to be tricky to get
right and is probably more than you want to get into right now.


Xen-devel mailing list