Re: [Xen-devel] [PATCH 00/18][V6]: PVH xen: version 6 patches...

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.06.13 at 19:14, Tim Deegan <tim@xxxxxxx> wrote:
> At 11:23 -0400 on 05 Jun (1370431396), Konrad Rzeszutek Wilk wrote:
>> On Fri, May 24, 2013 at 06:25:19PM -0700, Mukesh Rathor wrote:
>> > I've version 6 of my patches for 64bit PVH guest for xen.  This is Phase I.
>> > These patches are built on top of git
>> > c/s: 9204bc654562976c7cdebf21c6b5013f6e3057b3
>> > 
>> > V6:
>> > The biggest change in V6 is dropping of dom0 PVH. It will take some time
>> > to investigate and redo dom0 construct to use unmodified PV code. These 
>> > patches in V6 will allow PV dom0 to create PVH domU. Please ack or indicate
>> > individual patches if there are no issues, so I know they have been looked
>> > at.
>> 
>> Ian, Tim, Ian, George,
>> 
>> Are you guys waiting for Jan to review all the patches or just
>> the hypervisor ones before looking at the rest (say the libxl ones)?
> 
> I'm waiting for Jan right now (though I'll only be reviewing the
> hypervisor side anyway).  It takes me basically a whole day (i.e. my
> entire working week on Xen things right now) to review a series like
> this in any detail, so I'm afraid I'm waiting for Jan's feedback to be
> addressed before I read it again.  IIRC all the x86/mm concerns I had
> with early versions have been sorted out but a lot of things have
> changed since then.

And just to clarify - after having gone through the first several
patches of the most recent posting, the amount of changes I
asked for was large enough to make me stop spending significant
amounts of time on the rest of the series the 6th time.

And just to clarify for the future - now that I complained the 6th
time about simple coding style things, I'm going to not repeat
this exercise on this series again, but silently refrain from
considering it ready for getting applied until I can see that some
meaningful cleanup was really done (i.e. this doesn't mean I'm
not willing to take care of the occasional violation while
committing, but I'm tired of pointing out things that are obvious
looking at the raw patches).

The same, to a lesser degree, goes about other comments - I'm
simply not having the time to reiterate the same (or similar
recurring) problems on every submission again. After this long
a time, and several iterations, some common sense must be
possible to get applied to how such a patch series ought to be
structured and implemented.

Jan


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