On 10/03/2013 05:23 PM, Boaz Harrosh wrote:
On 10/03/2013 04:40 PM, Dan Mick wrote:
Yeah, that's always an option, but it's somewhat cumbersome; we did that
for a while with the rbd extensions to qemu, but they were pretty much
universally hated. I think an option string is cleaner. But I'm not
adamant. Any other opinions? (I have a prototype implementation; the
changes are small and obvious; end up in one new parameter to
(*bs_init)(lu, bsopts))
Go for it it is good for me. (I was just saying)
bsopts will that be a free form string or should we make it a name=value pair
and perhaps a common utility to extract those?
What is the CLI format of this:
--bsopts name1=value1:name2=value2
How did you implement this, or is there only one value supported?
I was thinking only one value, and I know it can't include comma (the
way tgtadm sends options), but otherwise it's freeform. (Actually there
might be other illegal chars; I should find out and specify.)
I was thinking of using it like "-o value --longopt=value" etc., but, as
it's freeform, backends can do whatever they like.
Or we could provide some more mechanism, but I figured since I'm the one
who wants it, I might be the only one who ever does.
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
