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

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



On Tue, 2012-04-24 at 15:58 +0100, Ian Jackson wrote:
> 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.

While I agree we also need to start being pragmatic about ever getting
4.2 out the door...

If it's a trivial job to support aa, ab etc then lets do it, if not then
lets leave it for 4.3?

> 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®.