[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v4 6/8] libxl: introduce libxl__alloc_vdev



Stefano Stabellini writes ("[Xen-devel] [PATCH v4 6/8] libxl: introduce 
libxl__alloc_vdev"):
> Introduce libxl__alloc_vdev: find a spare virtual block device in the
> domain passed as argument.
...
> +static char * libxl__alloc_vdev(libxl__gc *gc, uint32_t domid,
> +        char *blkdev_start, xs_transaction_t t)
> +{

If this function is ever called with domid != our own, this will
malfunction, because ...

> +            if (errno == ENOENT)
> +                return libxl__devid_to_localdev(gc, devid);

... libxl__devid_to_localdev only answers the question about the
current domain.

This needs to be mentioned in a documentation comment by the function,
at the very least.  Does your series invoke it with a domid other than
our own ?

> +            else
> +                return NULL;
> +        }
> +        vdev[strlen(vdev) - 1]++;
> +    } while (vdev[strlen(vdev) - 1] <= 'z');

There is a scaling limit here of not starting more than 26 domains
simultaneously.  Is that acceptable ?  I'm tempted to suggest not.
Note that "simultaneously" includes the case where all 27 of them are
simply sat waiting for someone to press "return" on a pygrub prompt.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.