Re: [Xen-devel] [v6][PATCH 10/16] tools: introduce some new parameters to set rdm policy

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Jul 08, 2015 at 08:43:41PM +0800, Chen, Tiejun wrote:
> On 2015/7/8 19:47, Ian Jackson wrote:
[...]
> >* On the question of option naming, the `reserve='.
> >
> >   Ian Campbell points out that the API structure for `[rdm_]reserve'
> >   as submitted is anomalous.  I agree with him.  The existing
> >   API and config file arrangements are rather too confusing.
> >
> >   Please change `reserve' to `policy', in the following places:
> >
> >   * In the xl rdm config parsing, `reserve=' should be `policy='.
> >   * In the xl pci config parsing, `rdm_reserve=' should be
> >     `rdm_policy='.
> >   * The type `libxl_rdm_reserve_flag' should be `libxl_rdm_policy'.
> >   * The field name `reserve' in `libxl_rdm_reserve' should be
> >     `policy'.
> >
> 
> Yes, we need to do this better. But this kind of argument really shouldn't
> finish just one week.
> 
> Just please go back to look at all emails started from our design
> (2014/12/26) to this revision, I believe all tool maintainers are CCed. And
> especially, these option name were changed a lot of times...
> 
> "flag" -> "reserve" -> "policy"
> "force" -> "strict"
> ....
> 
> Why didn't you guys say anything so long time? If you guys tried to give us
> this kind of comments or suggestions as early as possible, I believe you
> should can get that expected answer to your question.
> 

Just to be clear, we do appreciate the effort you put into this work.
Ian Campbell is happy with your clarification on what to expose on xl
level. Ian Jackson doesn't want to block this series on the ground of
documentations and default values.  We (tools maintainers) are also
convinced that the design is good enough for the current state of
affairs.

Renaming these fields and options is the only blocker for this series
to be accepted for 4.6 as far as tools maintainers concern. I understand
the frustration but renaming would not be too much work.

I can't speak for hypervisor maintainers though, they have their merits
on hypervisor patches.

Wei.

> But now this make both of us frustrated.
> 
> Thanks
> Tiejun
> 
> >
> >I think that with these changes I will be able to ack the remaining
> >tools parts of this series, and drop my objections to the parts acked
> >by Wei.
> >
> >I can't speak for the hypervisor side, which I haven't really looked
> >at.
> >
> >Ian.
> >
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel