Re: libxl: error handling before xenstored runs

[Vincent Hanquez <vincent.hanquez@eu.citrix.com>]

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