On Tue, Aug 27, 2013 at 10:34:54AM -0700, Ian Main wrote: > On Tue, Aug 27, 2013 at 03:28:07PM +0100, Daniel P. Berrange wrote: > > On Mon, Aug 26, 2013 at 12:30:39PM -0700, Ian Main wrote: > > > This patch changes virFileLoopDeviceOpen() to use the new loop-control > > > device to allocate a new loop device. If this behavior is unsupported > > > or an error occurs while trying to do this it falls back to the previous > > > method of searching /dev for a free device. > > > > > > With this patch you can start as many image based LXC domains as you > > > like (well almost). > > > > > > Fixes bug https://bugzilla.redhat.com/show_bug.cgi?id=995543 > > > > > > Signed-off-by: Ian Main <imain@xxxxxxxxxx> > > > --- > > > configure.ac | 12 +++++++++++ > > > src/util/virfile.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++++- > > > 2 files changed, 72 insertions(+), 1 deletion(-) > > > > > > > > > > #if defined(__linux__) && HAVE_DECL_LO_FLAGS_AUTOCLEAR > > > -static int virFileLoopDeviceOpen(char **dev_name) > > > + > > > +#if HAVE_DECL_LOOP_CTL_GET_FREE > > > +static int virFileLoopDeviceOpenLoopCtl(char **dev_name) > > > +{ > > > + int fd = -1; > > > + int devnr; > > > + char *looppath = NULL; > > > + > > > + VIR_DEBUG("Opening loop-control device"); > > > + if ((fd = open("/dev/loop-control", O_RDWR)) < 0) { > > > + virReportSystemError(errno, "%s", > > > + _("Unable to open /dev/loop-control")); > > > + return -1; > > > > We need to distinguish ENOENT (which should be non-fatal) from > > other (fatal) errors here. > > > > I'd suggest that we add an 'int *fd' parameter to this method, > > and use the return value to indicate success / failure only. > > > > eg, > > > > if (virFileLoopDeviceOpenLoopCtl(devname, &fd) < 0) > > return -1; > > if (fd == -1) > > fd = virFileLoopDeviceOpenSearch(devname); > > return fd; > > You bet. To be clear does this mean you don't want to fall back to the > search method in the case of an error while using loop-control > allocation? My thinking was we'd just give it a go regardless of the > issue.. nm, I see. heh Ian -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list