WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

[The mail reflector seems to have dropped the original of this so here's
another copy for the mail archive]

On Tue, 2005-03-01 at 03:46 +1100, Rusty Russell wrote:

> 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

<Prev in Thread] Current Thread [Next in Thread>