|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Re: blktap race against xenstore startup
On 2/10/06 10:36, "Stephen C. Tweedie" <sct@xxxxxxxxxx> wrote:
>>> The problem is not that xenstored is dead: it's alive and running, it
>>> just hasn't had the /local/domain tree filled in, so it returns ENOENT.
>>> xenstored *is* ready, but that's not enough.
>>
>> Set a watch on /local/domain and wait for the directory to appear? Not a
>> beautiful approach, but better than spinning a few times? :-)
>
> OK, I didn't realise we could set watches on non-existant paths in the
> store, but it seems like that should work.
Actually now you mention it I'm not 100% certain that you can; I'd need to
double check that. I think it's something we should allow even if not
though. Or you could set the watch on / and filter. Not much happens until
/local/domain is set up so you won't get many (any?) false watch firings.
> I was wondering if there was a way to synchronise against xend itself,
> though: doing it through the store is a little ugly. But yes, it's
> probably better than looping.
It's the obvious way of doing it imo. Xenstore is an always-available
service, even if we decide to disaggregate domain0 in future (e.g., move
blktap daemon to a different VM). I guess it depends on your p.o.v. :-)
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|