Re: [Xen-devel] [PATCH v3] RFC: extend the xenstore ring with a 'closing' signal

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2014-07-04 at 11:19 +0100, Dave Scott wrote:

> > 
> >> +CAMLprim value ml_interface_close(value interface)
> >> +{
> >> +  CAMLparam1(interface);
> >> +  const char invalid_data[] = { 'd', 'e', 'a', 'd', 'b', 'e', 'e', 'f' };
> >> +  struct xenstore_domain_interface *intf = GET_C_STRUCT(interface)->addr;
> >> +  int i;
> >> +
> >> +  intf->req_cons = intf->req_prod = intf->rsp_cons = intf->rsp_prod = 0;
> >> +  /* Ensure the unused space is full of invalid xenstore packets. */
> > 
> > Is filling with ones or zeroes not sufficient?
> > 
> > Also, is this strictly necessary of just for debugging purposes?
> 
> Itâs not strictly necessary so it could be removed.
> 
> My preference i to fill the unused space within the ring buffers with
> obviously invalid packets so that if someone peeks at it at the wrong
> time, they get obviously bad data and hopefully stop immediately. If
> both ends are operating correctly then they should never notice. Itâs
> unfortunate that all zeroes looks like a valid sequence of DEBUG
> packets. Perhaps I could fill it with â0xffâ and explicitly declare
> 0xff as an invalid message type xs_wire.h â that would do it.
> 
> What do you think?

One thought I just had was that this doesn't leave the ring in the
stated initial state (which is all zeroes). If something wanted to
resume using the ring it might expect that it was all zeroes?




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