Re: [Xen-devel] libxl: error handling before xenstored runs

[Vincent Hanquez <vincent.hanquez@xxxxxxxxxxxxx>]

On 10/02/11 11:24, Ian Campbell wrote:
> Right but this approach doesn't work with xenstored in a stubdomain.
yeah I know. xenstored in a stubdom is just an experiment, when it 
become a serious feature, this argument would hold. however it's not 
going to be use in 4.1, and in any production settings.
> Part of the point of using the ring protocol even when this isn't the
> case is to help ensure that it is possible and help avoid regressions
> etc.
>
> > The protocol is not design to do async either, so leaving unconsumed
> > request, could be pretty disastrous if the other end show up. Providing
> > the kernel doesn't detect it (i don't think it does [1]), it would imply
> > spurious reply, for example the previous waiting read on "/abc/def"
> > could reply to a next read on "/xyz/123".
> The wire protocol includes a req_id which is echoed in the response
> which sh/could facilitate multiplexing this sort of thing. The pvops
> kernel currently always sets it to zero but that's just an
> implementation detail ;-) Currently the kernel does (roughly):
The kernel is not the one exclusively setting the rid. this is a client 
initialized value. any xs implementation can use it any way they want 
(including the kernel implementation).
Turns out that most of the implementations are actually putting rid to 0 
anyway (the ocaml and C implementation are, the windows one isn't).
Even then, if you could initialize it to some value, what value is that 
going to be ? there's just no way to know if someone else is not using 
this rid already globally (since the ring is a global OS thing). Which 
basically would means tracking pid (the kernel meaning) along with the rid ?
> > > Maybe we should add an explicit ping/pong ring message to the xs ring
> > > protocol?
> > And who's going to reply to this if xenstored is missing ? you would
> > require the kernel to introspect the messages and reply by itself.
> The reason I suggested new messages was that I would solve that by
> declaring that these new messages have whatever magic semantics I need
> to make this work ;-)
ah right, the famous DeusExMachina message type then :-)

--
Vincent

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel