[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |