virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Zachary Amsden <zach@vmware.com>
Cc: Chris Wright <chrisw@sous-sol.org>, Andi Kleen <ak@muc.de>,
	Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
	Virtualization Mailing List <virtualization@lists.osdl.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/9] Vmi fix highpte
Date: Fri, 02 Mar 2007 23:43:54 -0800	[thread overview]
Message-ID: <45E9273A.4040300@goop.org> (raw)
In-Reply-To: <45E920F6.7060806@vmware.com>

Zachary Amsden wrote:
> Yes, but the hook point now happens before the page table mapping.

Did you change that since you posted the patch?  Sounds like a larger
change than the one I'm proposing.

>   Not that it should cause a problem.  But we've been testing things
> the original way for over a year now, and if we want to get the fix
> upstream for 2.6.21, it seems better to upstream a more tested fix
> rather than a new way of doing things, even if it is identical in theory.

Sure.

> That said, I have no problems with the approach you propose going
> forward.  I just don't think it is appropriate for an -rc release,
> because it provides no tangible benefit for any of the in-kernel code,
> and causes a lot of retesting.  I still believe there is almost zero
> risk to doing things the way you propose.  But I am also a firm
> believer in shipping what is tested and working unless there is a
> compelling reason to do otherwise.  And if Xen is not going to be in
> 2.6.21, the compelling reason becomes getting the code working for
> both of us for 2.6.22 - so let's do that, and keep the patches from
> Andrew's -mm tree around to make sure that we have a suitable patch
> base that can be applied to 2.6.21 for any distros that are willing to
> pick up the Xen paravirt-ops.
>
> Sound reasonable?

I can deal with the change going into -git, but it does seem awkward
knowing that it is the wrong change and it will be replaced by something
else almost immediately.

My main concern is that the Xen patch queue is complex enough as-is, and
I've been trying hard to remove dependencies on other uncommitted
patches.   It's doubly complex because I'm not really sure if I'm
targeting Andrew or Andi's tree as a base, though at the moment -git
seems to work either way.

    J

  reply	other threads:[~2007-03-03  7:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-02  2:54 [PATCH 4/9] Vmi fix highpte Zachary Amsden
2007-03-02  3:08 ` Jeremy Fitzhardinge
2007-03-02  3:39   ` Jeremy Fitzhardinge
2007-03-02  6:24     ` Zachary Amsden
2007-03-02  6:29       ` Jeremy Fitzhardinge
2007-03-02  6:31     ` Zachary Amsden
2007-03-02  6:45       ` Jeremy Fitzhardinge
2007-03-02  9:53         ` Zachary Amsden
2007-03-02 16:55           ` Jeremy Fitzhardinge
2007-03-03  7:17             ` Zachary Amsden
2007-03-03  7:43               ` Jeremy Fitzhardinge [this message]
2007-03-03  7:58                 ` Zachary Amsden

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45E9273A.4040300@goop.org \
    --to=jeremy@goop.org \
    --cc=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=chrisw@sous-sol.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    --cc=virtualization@lists.osdl.org \
    --cc=zach@vmware.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).