Am 29.09.2016 um 13:07 hat Daniel P. Berrange geschrieben: > On Thu, Sep 29, 2016 at 12:42:34PM +0200, Kevin Wolf wrote: > > Am 29.09.2016 um 10:07 hat Richard W.M. Jones geschrieben: > > > On Thu, Sep 29, 2016 at 01:05:48PM +0530, Ashijeet Acharya wrote: > > > > Hi all, > > > > > > > > I was trying to convert SSH driver to support 'blockdev-add' and so > > > > far I have tried to figure out what the struct 'BlockdevOptionsSsh' in > > > > block-core.json should look like, > > > > > > > > { 'struct': 'BlockdevOptionsSsh', > > > > 'data': { 'tcp': 'InetSocketAddress', > > > > 'path': 'str' } } > > > > > > > > Naive question but I have to ask, Am I missing something? > > > > > > > > As far as I know, ssh only supports 'tcp' right? So using > > > > 'InetSocketAddress' should be good enough. (like the TODO says) > > > > > > > > I had a discussion with Kevin about this and he thinks, maybe > > > > 'SocketAddress' can be used too because the restriction comes from the > > > > qemu block driver rather than the backend. He advised me to get an > > > > opinion on this one from the maintainers of SSH. > > > > > > I have no idea. > > > > I searched the net a bit and it seems that SSH over Unix domain sockets > > isn't a thing. So it might actually be okay to restrict the QEMU block > > driver to TCP, too, and therefore use InetSocketAddress. > > > > Any other opinions? > > We have multiple block device drivers that all need network addresses. > I think it'd be nice if we can use the same schema for all of them, > even if some of them don't (currently) require certain options. > > eg rename 'GlusterServer' to 'BlockServer' and use it for all nework > transports. Those that don't want unix support can just reject it > at runtime, likewise those that don't need multiple-server support. > > This will let mgmt apps have the same code for generating the > blockdev options for all network based transports, instead of having > to write different code for each.
Allowing everything and then rejecting things at runtime isn't really the idea behind having a schema... It would also make it impossible for libvirt to detect whether a new backend has been implemented. If we do schemas properly and only advertise what's really there, schema introspection can answer that question. Kevin