|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 28/31] libxl: provide libxl__openpty_*
On Tue, 2012-04-10 at 20:08 +0100, Ian Jackson wrote:
> General facility for ao operations to open ptys.
>
> This will be used by the bootloader machinery.
>
> Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> ---
> tools/libxl/libxl_aoutils.c | 127
> ++++++++++++++++++++++++++++++++++++++++++
> tools/libxl/libxl_internal.h | 36 ++++++++++++
> 2 files changed, 163 insertions(+), 0 deletions(-)
>
> diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
> index c1229e4..b33abe4 100644
> --- a/tools/libxl/libxl_aoutils.c
> +++ b/tools/libxl/libxl_aoutils.c
[...]
> +int libxl__openptys(libxl__openpty_state *op,
> + const struct termios *termp,
> + const struct winsize *winp) {
> + /*
> + * This is completely crazy.
;-)
> openpty calls grantpt which the spec
> + * says may fork, and may not be called with a SIGCHLD handler.
> + * Now our application may have a SIGCHLD handler so that's bad.
> + * We could perhaps block it but we'd need to block it on all
> + * threads. This is just Too Hard.
> + *
> + * So instead, we run openpty in a child process. That child
> + * process then of course has only our own thread and our own
> + * signal handlers. We pass the fds back.
> + *
> + * Since our only current caller actually wants two ptys, we
> + * support calling openpty multiple times for a single fork.
> + */
> + STATE_AO_GC(op);
> + int count = op->count;
> + int r, i, rc, sockets[2], ptyfds[count][2];
> + libxl__carefd *for_child = 0;
> + pid_t pid = -1;
> +
> + for (i=0; i<count; i++) {
> + ptyfds[i][0] = ptyfds[i][1] = -1;
> + libxl__openpty_result *res = &op->results[i];
> + assert(!res->master);
> + assert(!res->slave);
> + }
> + sockets[0] = sockets[1] = -1; /* 0 is for us, 1 for our child */
> +
> + libxl__carefd_begin();
> + r = socketpair(AF_UNIX, SOCK_STREAM, 0, sockets);
> + if (r) { sockets[0] = sockets[1] = -1; }
> + for_child = libxl__carefd_opened(CTX, sockets[1]);
> + if (r) { LOGE(ERROR,"socketpair failed"); rc = ERROR_FAIL; goto out; }
> +
> + pid = libxl__ev_child_fork(gc, &op->child, openpty_exited);
> + if (pid == -1) {
> + rc = ERROR_FAIL;
> + goto out;
> + }
> +
> + if (!pid) {
> + /* child */
> + close(sockets[0]);
> + signal(SIGCHLD, SIG_DFL);
> +
> + for (i=0; i<count; i++) {
> + r = openpty(&ptyfds[i][0], &ptyfds[i][1], NULL, termp, winp);
> + if (r) { LOGE(ERROR,"openpty failed"); _exit(-1); }
> + }
> + rc = libxl__sendmsg_fds(gc, sockets[1], "",1,
> + 2*count, &ptyfds[0][0], "ptys");
> + if (rc) { LOGE(ERROR,"sendmsg to parent failed"); _exit(-1); }
Buried in this LOGE is a CTX somewhere, right? Is it valid to keep using
it? Perhaps it's OK just for this logging.
I suppose we don't need to call the postfork-noexecing handler because
we are inside libxl?
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |