|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH V4 24/24] xl: update configuration when we unplug a device
On Tue, May 06, 2014 at 04:55:33PM +0100, Ian Campbell wrote:
> On Thu, 2014-05-01 at 13:58 +0100, Wei Liu wrote:
> > Some macros are written to accomplish following tasks:
> > 1. load domain configuration
> > 2. allocate a new array of devices
> > 3. copy the devices that are to be remain in configuration
>
> s/are to be// and s/in/into/.
>
> > 4. replace pointer in libxl_domain_config
> > 5. store domain configuration
> >
> > Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx>
> > ---
> > tools/libxl/xl_cmdimpl.c | 83
> > ++++++++++++++++++++++++++++++++++++++--------
> > 1 file changed, 69 insertions(+), 14 deletions(-)
> >
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index 91172c5..ae3df6e 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -411,6 +411,59 @@ static void *xrealloc(void *ptr, size_t sz) {
> > libxl_domain_config_dispose((d_config)); \
> > } while (0)
> >
> > +#define COMPARE_DEVID(a, b) ((a)->devid == (b)->devid)
> > +#define COMPARE_DISK(a, b) (!strcmp((a)->vdev, (b)->vdev))
> > +#define COMPARE_PCI(a, b) ((a)->bus == (b)->bus && \
> > + (a)->dev == (b)->dev && \
> > + (a)->func == (b)->func)
> > +
> > +/* Remove / destroy a device and update the stored configuration */
> > +#define REMOVEDESTROY_DEVICE(devtype,domid,dev,ptr,cnt, \
> > + compare,removedestroy) \
>
> You've been talking to Ian J haven't you :-P
>
Many times. :-)
> > + do { \
> > + libxl_domain_config d_config; \
> > + libxl_device_ ## devtype *p = NULL, *x; \
> > + int num; \
> > + int j, k; \
> > + \
> > + libxl_domain_config_init(&d_config); \
> > + load_domain_config((domid), &d_config); \
> > + \
> > + k = 0; \
> > + for (j = 0; j < d_config.cnt; j++) { \
> > + x = d_config.ptr + j; \
> > + if (compare(x, &(dev))) \
>
> Are you concerned with the possibility that two entries in the array
> might match dev? Wouldn't that equate to e.g. two xvda devices? Should
> we not reject such things elsewhere?
>
Yes. And it's not just concern, I've seen this already!
The current xl block-attach doesn't complain if you add same CD images
twice.
> > + k++; \
> > + } \
> > + \
> > + num = d_config.cnt - k; \
> > + \
> > + p = xrealloc(p, sizeof(*p) * num); \
>
> Why realloc, isn't the input p always NULL? (turning it into xmalloc).
>
Oh I missed xmalloc.
> But couldn't this be done in place, with a little care?
>
> for(i = j = 0; i < d_config.cnt; i++)
> if (!compare(d_config.ptr[i], dev)
> d_config.ptr[j] = d_config.ptr[i] /* XXX optimise/skip if j ==
> i */
> j++
> (note that j <= i is always true)
>
> then realloc the array down to only j entries.
>
This can be done. Will use this approach.
> > + \
> > + k = 0; \
> > + for (j = 0; j < d_config.cnt; j++) { \
> > + x = d_config.ptr + j; \
> > + if (compare(x, &(dev))) \
> > + continue; \
> > + libxl_device_ ## devtype ## _copy(ctx, &p[k], \
> > + d_config.ptr + j); \
>
> Same comment as the previous patch re the actual need for a deep copy.
>
This is a bit different because we don't need to fix up when removing a
device. And with your approach this deep copy is not necessary.
Wei.
> Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |