[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xl: support empty CDROM devices
Ian Campbell writes ("Re: [Xen-devel] [PATCH] xl: support empty CDROM devices"): > On Wed, 2012-07-25 at 17:06 +0100, Ian Jackson wrote: > > Ian Campbell writes ("Re: [Xen-devel] [PATCH] xl: support empty CDROM > > devices"): > > > diff -r 097bf63027e0 tools/libxl/libxlu_disk.c > > > --- a/tools/libxl/libxlu_disk.c Wed Jul 25 11:21:55 2012 +0100 > > > +++ b/tools/libxl/libxlu_disk.c Wed Jul 25 17:00:00 2012 +0100 > > > @@ -78,6 +78,8 @@ int xlu_disk_parse(XLU_Config *cfg, > > > disk->readwrite = 0; > > > if (!disk->pdev_path || !strcmp(disk->pdev_path, "")) > > > disk->format = LIBXL_DISK_FORMAT_EMPTY; > > > + } else if (disk->format == LIBXL_DISK_FORMAT_EMPTY) { > > > + disk->format = LIBXL_DISK_FORMAT_RAW; > > > } > > > > This is rather odd. It appears to turn empty non-cdroms into RAW. Is > > that actually correct ? It doesn't seem likely to me that it is. I > > think my new arrangements don't generate empty non-cdroms unless the > > user explicitly specifies `empty' as the format or uses the xend > > compatibility syntax and explicitly specifies `:disk'. > > I think empty is meaningless for anything except cdroms. This was here > because in my version the parser didn't know it had a cdrom at the point > where it had to decide to make the device empty so I fixed it up here. I > think you are right that your version doesn't require it. Right. I think the later code in libxl will reject empty non-cdroms so we are fine without this hunk. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |