Re: [Xen-devel] [PATCH v3 17/28] tools/libxl: Infrastructure for reading a libxl migration v2 stream

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Andrew Cooper writes ("[PATCH v3 17/28] tools/libxl: Infrastructure for reading 
a libxl migration v2 stream"):
...
> +static void write_emulator_blob(libxl__egc *egc,
> +                                libxl__stream_read_state *stream,
> +                                libxl__sr_record_buf *rec)
...
> +    libxl__carefd_begin();
> +    writefd = open(path, O_WRONLY | O_CREAT | O_TRUNC, 0600);
> +    if (writefd == -1) {
> +        rc = ERROR_FAIL;
> +        LOGE(ERROR, "unable to open %s", path);
> +        libxl__carefd_unlock();
> +        goto err;
> +    }

I have just spotted something else which I think both of us missed
from my review of v2:

I wrote:

    If [you keep using carefd for this], then please use
    libxl__carefd_opened.  (Best would be to libxl__carefd_opened to
    save and restore errno and then you can call it unconditionally
    after the open.)

I meant `best would be to _change_ libxl__carefd_opened save and
restore errno'.

> +    assert(stream->emu_carefd == NULL);
> +    stream->emu_carefd = libxl__carefd_opened(CTX, writefd);

And then call it _unconditionally_, _immediately after_ the open.

This means that the carefd functions bracketing open are easy to see
and there is no entanglement with error-handling flow control.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel