[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.