|
[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 |