From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vincent Hanquez Subject: Re: libxl: error handling before xenstored runs Date: Thu, 10 Feb 2011 21:55:10 +0000 Message-ID: <4D545EBE.1060501@eu.citrix.com> References: <201102091213.06591.Christoph.Egger@amd.com> <4D52B5DD.2060900@gmail.com> <201102091652.09218.Christoph.Egger@amd.com> <201102091654.29318.Christoph.Egger@amd.com> <1297273192.29419.7.camel@qabil.uk.xensource.com> <1297328120.1047.21.camel@zakaz.uk.xensource.com> <4D53AF37.9010204@eu.citrix.com> <1297337081.20491.132.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1297337081.20491.132.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: Kamala Narasimhan , Christoph Egger , "xen-devel@lists.xensource.com" , Gianni Tedesco List-Id: xen-devel@lists.xenproject.org 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