Re: [Xen-devel] [PATCH 06/10 V7] remus: implement the API to buffer/release packages

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Lai Jiangshan writes ("[PATCH 06/10 V7] remus: implement the API to 
buffer/release packages"):
> This patch implements two APIs:
> 1. libxl__remus_netbuf_start_new_epoch()
>    It marks a new epoch. The packages before this epoch will
>    be flushed, and the packages after this epoch will be buffered.
>    It will be called after the guest is suspended.
> 2. libxl__remus_netbuf_release_prev_epoch()
>    It flushes the buffered packages to client, and it will be
>    called when a checkpoint finishes.

Thanks.

> +_hidden int libxl__remus_netbuf_start_new_epoch(libxl__gc *gc, uint32_t dom\
id,
> +                                               libxl__remus_state *remus_st\
ate);
> +
> +_hidden int libxl__remus_netbuf_release_prev_epoch(libxl__gc *gc, uint32_t \
domid,
> +                                                  libxl__remus_state *remus\
_state);

I'd really appreciate it if you could wrap or otherwise reformat the
long lines in these patches.  As you can see, they appear on my screen
with pretty bad wrap damage otherwise.

> +        if (buffer_op == tc_buffer_start)
> +            ret = rtnl_qdisc_plug_buffer(netbuf_state->netbuf_qdisc_list[i]);
> +        else
> +            ret = 
> rtnl_qdisc_plug_release_one(netbuf_state->netbuf_qdisc_list[i]);
> +
> +        if (!ret)
> +            ret = rtnl_qdisc_add(netbuf_state->nlsock,
> +                                 netbuf_state->netbuf_qdisc_list[i],
> +                                 NLM_F_REQUEST);

This error handling approach is unconventional for libxl.  The correct
approach would be to explicitly check after the first call.  If you
really want to have only one logging point, you can do that in your
"out:" section (reached via "goto out").

I confess I don't understand why this patch is broken out at this
point.  It provides these two functions but not yet any callers.  Is
that right ?

Thanks,
Ian.

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