Dan Smith wrote:
KR> Just a nit-picky thing here... why not call the
AllocCapabilities
KR> function that setups the instance? I think using the same
KR> InstanceID for the AllocCapa as the pool might not always return
KR> the correct instance because AllocCapa uses <pool type>/0 as the
KR> InstanceID. But something like the NetworkingPool returns
KR> "NetworkPool/xenbr0". So you'll be creating an instance with
KR> "NetworkPool/xenbr0" as the InstanceID, which would conflict with
KR> what EnumInstances from AllocCapa would return.
I think AllocationCapabilities needs to change here. It think using
the InstanceID from the pool makes the most sense. I'm not sure what
the existing AllocationCapabilities stuff intended, but I'm assuming
it will need to change to match this new stuff. Perhaps it was a
hold-over from the days of one-pool-per-resource-type?
Good catch, by the way :)
Just to be clear, copying InstanceID from the instance of ResourcePool
to the instance of AllocationCapabilities is okay, but I need to change
the AllocationCapabilities provider? That doesn't much surprise me; the
AllocationCapabilities provider itself only exists so I could register
it as a class; I'm honestly not even sure what it's supposed to do on
its own
. Reading through the entire Allocation Capabilities Profile (DSP1043)
provides no insight into what get/enumerateInstance(s) would do.
Reasonable detail is given about how it should be connected to things
via associations, but there isn't much concept of a standalone instance.
--
-Jay