The format in which disk information is required in xl block-attach is different than the one expected in the disk configuration option (in the config file). It might make sense to keep the two consistent (excluding the domain/backend dom id additional param block-attach would require). Would it be alright if I enforce it in our implementation (in main_blockattach in xl_cmdimpl.c) and modify block-attach help to reflect that change? Kamala _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sun, 2011-01-30 at 19:56 +0000, Kamala Narasimhan wrote:> The format in which disk information is required in xl block-attach is different > than the one expected in the disk configuration option (in the config file). It > might make sense to keep the two consistent (excluding the domain/backend dom id > additional param block-attach would require). Would it be alright if I enforce > it in our implementation (in main_blockattach in xl_cmdimpl.c) and modify > block-attach help to reflect that change?I think it makes sense to have them be the same (or as similar as possible). OOI, do the xm block-attach and xm config syntaxes differ from each too? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell wrote:> On Sun, 2011-01-30 at 19:56 +0000, Kamala Narasimhan wrote: >> The format in which disk information is required in xl block-attach is different >> than the one expected in the disk configuration option (in the config file). It >> might make sense to keep the two consistent (excluding the domain/backend dom id >> additional param block-attach would require). Would it be alright if I enforce >> it in our implementation (in main_blockattach in xl_cmdimpl.c) and modify >> block-attach help to reflect that change? > > I think it makes sense to have them be the same (or as similar as > possible). > > OOI, do the xm block-attach and xm config syntaxes differ from each too? >I think so. The disk config syntax passed to xm through a config file is different than xm block-attach syntax. Kamala _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, 2011-01-31 at 15:10 +0000, Kamala Narasimhan wrote:> Ian Campbell wrote: > > On Sun, 2011-01-30 at 19:56 +0000, Kamala Narasimhan wrote: > >> The format in which disk information is required in xl block-attach is different > >> than the one expected in the disk configuration option (in the config file). It > >> might make sense to keep the two consistent (excluding the domain/backend dom id > >> additional param block-attach would require). Would it be alright if I enforce > >> it in our implementation (in main_blockattach in xl_cmdimpl.c) and modify > >> block-attach help to reflect that change? > > > > I think it makes sense to have them be the same (or as similar as > > possible). > > > > OOI, do the xm block-attach and xm config syntaxes differ from each too? > > > > I think so. The disk config syntax passed to xm through a config file is > different than xm block-attach syntax.What are the syntaxes and how are they different? I was under the impression that (roughly speaking) the comma separated stuff in the config file simply became the individual arguments to block-attach, is that not the case? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell wrote:> On Mon, 2011-01-31 at 15:10 +0000, Kamala Narasimhan wrote: > What are the syntaxes and how are they different? I was under the > impression that (roughly speaking) the comma separated stuff in the > config file simply became the individual arguments to block-attach, is > that not the case? >Kind of but not quite. Here is what I get from block-attach help (both xl/xm return the same btw) - ********* Usage: xl [-v] block-attach <Domain> <BackDev> <FrontDev> [<Mode>] [BackDomain] Create a new virtual block device. *********>From the above it is not very evident what is acceptable for BackDev andFrontDev. So I looked at the code that parses these input (in xl). It takes backdev and looks for pdev type (''phy'' or ''file'' or ''tap'') and if tap, looks for ''aio'' or ''vhd'' or ''qcow'' or ''qcow2'' (here it is mixing format with backend impl type) followed by pdev path. It then takes frontdev and interprets it to be vdev path and then it interprets mode to be read or write attribute. We could still keep the higher level arguments as is but our parser could interpret BackDev and FrontDev values the way it does for config file option. The way I have refactored the disk config parsing code (by dividing it into pdev/vdev/attrib chunks for parsing, we can simply reuse that parsing code in block-attach too! Kamala _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, 2011-01-31 at 16:45 +0000, Kamala Narasimhan wrote:> From the above it is not very evident what is acceptable for BackDev > and FrontDev. So I looked at the code that parses these input (in > xl). It takes backdev and looks for pdev type (''phy'' or ''file'' or > ''tap'') and if tap, looks for ''aio'' or ''vhd'' or ''qcow'' or ''qcow2'' (here > it is mixing format with backend impl type) followed by pdev path. > It then takes frontdev and interprets it to be vdev path and then it > interprets mode to be read or write attribute.Possible implementation bugs and lack of code reuse aside it sounds as if the intention was to support the same stuff as the configuration file.> We could still keep the higher level arguments as is but our parser > could interpret BackDev and FrontDev values the way it does for config > file option.That sounds sensible to me. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel