Re: Re: Re: [Xen-devel] Proposal for init/kexec/hotplug format for Xen

[Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

> So ignore my code and look at an explicit Xen interface to such a store,
> rather than having the domain keep track of their own copy.

I'm trying to get stuck into the USB code as not having finished it is
starting to look a bit lame.  I was assuming that you, Keir and Anthony
were looking at this stuff.

In any case, I'm not sure you want an explicit Xen interface for this.
It should be sufficient to define a good IDC API for Xen and then build
on top of that.

The registry is just a service accessible to a domain using the IDC API.

You need to solve the bootstrap issue for domain 0: two obvious
alternatives: A) have a root registry inside Xen and then domain 0 can
have the same interface as the other domains or B) push everything out
into domain 0 in a platform specific way and then have domain 0 build a
root registry out of the platform specific discovery.

I was under the impression that the architectural direction was to push
as much as possible out of Xen into domain 0 which is consistent with
the second alternative.

In a clustered system with FT domains, the code running in the FT domain
would be provided with access (over the IDC API) to one registry per
base domain which would give it hotplug notification about the devices
accessible via that base domain. This means that the code in the FT
domain would access multiple registries over the IDC API and pool the
results, doing multipathing for any devices which were accessible
through multiple base domains. OK, I'll take my bunny off the boil now.

The key to success is a good IDC API.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel