From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [v4][PATCH 11/19] tools: introduce some new parameters to set rdm policy Date: Thu, 02 Jul 2015 19:32:42 +0800 Message-ID: <5595215A.8080900@intel.com> References: <1435053450-25131-1-git-send-email-tiejun.chen@intel.com> <1435053450-25131-12-git-send-email-tiejun.chen@intel.com> <55933F7C.2050607@intel.com> <5593BBC8.1010402@eu.citrix.com> <5593C063.7000705@intel.com> <5593C7AC.8030901@eu.citrix.com> <5593CC19.9020200@intel.com> <5593EB53.5000601@eu.citrix.com> <55948FA7.8020007@intel.com> <559502D6.5040603@eu.citrix.com> <55950C10.2000307@intel.com> <5595125B.20808@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5595125B.20808@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: Ian Jackson , Stefano Stabellini , Wei Liu , Ian Campbell , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 2015/7/2 18:28, George Dunlap wrote: > On 07/02/2015 11:01 AM, Chen, Tiejun wrote: >>> 1. After spending yet another half hour doing research, I haven't found >>> any discussion that concluded we should have the global policy override >>> the local policy >> >> I also took some time to go back checking this point and indeed this is >> not in that public design. And as I mentioned in another email which is >> following this, I also had a talk to Kevin about this issue, and looks >> this is just concluded from our internal discussion and he didn't post >> this in v2 design again because as you know, that design is about >> something in high level. And as I recall, these discussions can't cover >> everything at that moment because they thought we'd better post a >> preliminary patches to further discuss something since this is really a >> complicated case. So afterwards I sent out two RFC revisions to help all >> guys finalize a good solution. And I can confirm current policy is >> always same from the first RFC, but we didn't see any opposite advice >> until now. > > Probably because the reviewers all assumed that the design draft had > been followed, and you didn't make it clear that you'd changed it. Shouldn't the patch head description already clarify this point? And I also comment this point in the code. After all, we already had several rounds of technical reviews so its a little hard to believe it was not obvious to be missed. > >>> 2. The only discussion I *did* find has *you yourself* saying that the >>> per-device setting should override the global setting, not once, but >>> twice; and nobody contradicting you. >>> >>> Maybe there is somewhere else a discussion somewhere where this was >>> changed; but I've already spent half an hour this morning looking at >>> where you said it was (v2 design discussion), and found the opposite -- >>> just as I remembered. I'm not going to look anymore. >>> >>> You have now caused me to waste an awful lot of time on this series that >>> could profitably have been used elsewhere. >> >> Sorry to this but I just think we already have 2 RFC revisions and 4 >> revisions without RFC, and some patches are already Acked, we really >> should overturn this policy right now? > > First of all, I think it's easy to change. > I agree but what I'm saying is this is involving our policy. It shouldn't change this sort of thing if not all associated maintainers are in the agreement with you. > Even if it weren't, I already said that I'd be OK with accepting the > patch series with the existing "override" semantics, and without the > "default" semantics, *if* it were renamed to make it clear what was > going on. > > But, for future reference, I am not going to approve an interface I > think is misleading or wrong -- particularly one like the xl interface > which we want to avoid changing if possible -- just because time is > short. One of my own features, HVM USB pass-through, has narrowly > missed two releases (including the current one) because we wanted to be > careful to get the interface right. I admit I should concern everything carefully like you. > >>>> Again, I didn't walk into v2 design. So here I don't want to bring any >>>> confusion to you just with my reply. >>> >>> This is your feature, so it is your responsibility to understand and >>> explain why you are doing what you are doing, if only to say "Jan wanted >> >> Maybe you remember I just posted v1 but looks that was not a better >> design to show this implementation according to some feedback, so Kevin >> issued v2 revision and had a wider discussion with you guys. Since then >> I just follow this version. So I mean I don't further hold these things >> in high level since I just think both policy is fine to me because IMO, >> these two approaches are optional. >> >>> X to happen because of Y [see $ref]." >>> >> >> So this is why I said you'd better ask this to Kevin or Jan since I >> can't decide what's next at this point. > > Let me say that again: I don't care whether anyone "pulled rank" and > ordered you to do something a certain way. YOU are the one submitting > this patch. That means YOU responsible for understanding why they want > it that way, and YOU are responsible for justifying it to other people. > If you don't understand it at all, it's YOUR responsibility to get them > to explain it, not mine to chase them down. > As I said above I thought initially they're optional, and just about which one is a preference. So I picked up these patch descriptions reviewed in public to say this is our expectation. But looks this is not satisfied to you, so I don't think I can further explain this kind of thing appropriately, and then I ask you to ping Jan or Kevin to get a formal answer. Is this procedure not reasonable? Thanks Tiejun