On 09/22/2010 09:20 PM, Joerg Roedel wrote:
On Wed, Sep 22, 2010 at 07:47:06PM +0200, Gleb Natapov wrote:
> On Wed, Sep 22, 2010 at 06:29:00PM +0200, Nadav Har'El wrote:
> > In any case, while I obviously agree that it's your prerogative not to merge
> > code that you consider ugly, I still don't see any particular problem to start
> > with the current, working, code, and fix it later. It's not like we can never
> > change this code after it's in - it's clearly marked with if(nested) and
> > doesn't effect anything in the non-nested path.
> >
> After code it merged there is much less incentive to change things
> drastically.
I think nested svm is a good counter example to that. It has drastically
improved since it was merged. Ok, it hasn't _changed_ drastically, but
what drastic changes do we expect to become necessary in the nested-vmx
code?
I don't expect drastic changes, but then, I still don't understand it well.
Part of the review process is the maintainer becoming familiar (and, in
some cases, comfortable) with the code. The nit-picking is often just
me proving to myself that I understand what's happening.
btw, speaking of drastic changes to nsvm, one thing I'd like to see is
the replacement of those kmaps with something like put_user_try() and
put_user_catch(). It should be as fast (or faster) than kmaps, and not
affect preemptibility.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
