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.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home