Hi Stefan, I had replied to the QEMUBH suggestion in the email below.
Regards, Ashish On Tue, Aug 23, 2016 at 3:22 PM, ashish mittal <ashmit...@gmail.com> wrote: > Thanks Stefan, I will look at block/quorum.c. > > I have sent V4 of the patch with a reworked parsing logic for both > JSON and URI. Both of them are quite compact now. > > URI parsing now follows the suggestion given by Kevin. > /================/ > However, you should use the proper interfaces to implement this, which > is .bdrv_parse_filename(). This is a function that gets a string and > converts it into a QDict, which is then passed to .bdrv_open(). So it > uses exactly the same code path in .bdrv_open() as if used directly with > QAPI. > /================/ > > Additionally, I have fixed all the issues pointed out by you on V1 of > the patch. The only change I haven't done is to replace pipes with > QEMUBH. I am hoping this will not hold up the patch from being > accepted, and I can make this transition later with proper dev and > testing. > > Regards, > Ashish > > > On Tue, Aug 23, 2016 at 2:58 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: >> On Sat, Aug 20, 2016 at 11:42:22AM -0700, ashish mittal wrote: >>> I'm trying to understand how I can parse a json command line having >>> multiple server list (InetSocketAddressList) without the QemuOpts -> >>> QDict -> QAPI conversion that I am currently doing. >>> >>> block/nbd.c has been suggested, but it only parses a single host >>> entry, which is pretty straightforward, but not very helpful. >>> >>> Could somebody please suggest a sample implementation (other than >>> gluster.c) that parses a list of server like options in the json >>> format? >> >> Another block driver that takes an array of objects is block/quorum.c. >> See quorum_open() and how it picks out "children." objects. >> >> I haven't read the full discussion in this thread but maybe that's what >> you're looking for. >> >> Stefan
