Re: [RFC] support more qdisk types

[Wei Liu <wei.liu2@citrix.com>]

On Wed, Feb 03, 2016 at 11:05:04AM +0000, Ian Campbell wrote:
> On Wed, 2016-02-03 at 10:55 +0000, Wei Liu wrote:
> > On Wed, Feb 03, 2016 at 10:51:27AM +0000, Ian Campbell wrote:
> > > On Wed, 2016-02-03 at 10:35 +0000, Wei Liu wrote:
> > > > > Ok. So in your opinion, even if any new disk config is encoded in
> > > > > 'target=',
> > > > > libxlu should split that up into (new) members of
> > > > > libxl_device_disk, not just
> > > > > plop it into libxl_device_disk.pdev_path?
> > > > > 
> > > > 
> > > > No, not necessarily. I didn't look closely in the code yesterday when
> > > > replying, sorry.
> > > > 
> > > > If  target= has always been shoveled into pdev_path, using that would
> > > > be
> > > > fine. We already have mechanism to parse target= outside of libxl in
> > > > hotplug script.
> > > > 
> > > > Are you aware of all those hotplug scripts living under tools/hotplug
> > > > ?
> > > > Does using hotplug script sound plausible to you?
> > > > 
> > > > Currently hotplug script for QEMU is broken and needs fixing though,
> > > > but
> > > > I'm sure we can figure it out.
> > > 
> > > How do hotplug scripts factor into this?
> > > 
> > 
> > If supporting all such block devices  requires presenting a block device
> > to QEMU? If QEMU directly handles them then hotplug script is not in the
> > picture.
> 
> Perhaps I've misunderstood what this thread is about. I thought it was
> about exposing all the various backends which qdisk supports natively, like
> CEPH, sheepdog, iscsi, nbd etc.
> 

Good point. It is me who is confused. Hotplug is not in the picture
then.

Wei.

> Ian.