From: Markus Armbruster <armbru@redhat.com>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: Jeremy Katz <katzj@redhat.com>,
aliguori <aliguori@mail.utexas.edu>,
xen-devel <xen-devel@lists.xensource.com>,
sos22@srcf.ucam.org
Subject: Re: [PATCH] Paravirt framebuffer frontend kernel support [1/5]
Date: Thu, 21 Sep 2006 20:41:13 +0200 [thread overview]
Message-ID: <874pv1m59y.fsf@pike.pond.sub.org> (raw)
In-Reply-To: <C124AE2E.23E8%Keir.Fraser@cl.cam.ac.uk> (Keir Fraser's message of "Wed, 06 Sep 2006 16:56:14 +0100")
Keir Fraser <Keir.Fraser@cl.cam.ac.uk> writes:
> On 6/9/06 10:11 am, "Steven Smith" <sos22-xen@srcf.ucam.org> wrote:
>
>>> I wouldn't complain if we go the route Keir suggested and have Xen do
>>> it ;-) But if not, I think that given the size of the memory in
>>> question + grant tables, the quick hack is probably going to be the
>>> "right" thing for this case.
The quick hack being translating mfns in the backend.
>> Okay. Adding translations to the hypervisor isn't going to happen
>> until after 3.0.3, so we should probably just leave this for a little
>> while.
>
> Another option after 3.0.3 is to allow grant tables to support these large
> mappings. I have some ideas how to do this fairly efficiently, given that
> it'll be okay to track mappings to all the pages as an aggregate. It's not
> going to happen for now though -- it'll just be a shame if we add
> grant-table support later that it'll change the setup protocol. However, we
> can probably maintain backward compatibility if we think about it a bit.
>
> -- Keir
Is there anything we can do now to help with maintaining backward
compatibility later?
Evolving interfaces are a fact of life. What about versioning?
Frontend puts its interface version in xenstore, bump it when we
change stuff (which should happen very rarely, of course), backend
queries the version and does the right thing.
next prev parent reply other threads:[~2006-09-21 18:41 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-02 19:58 [PATCH] Paravirt framebuffer frontend kernel support [1/5] Jeremy Katz
2006-09-04 9:00 ` Steven Smith
2006-09-04 14:03 ` Keir Fraser
2006-09-05 16:11 ` Jeremy Katz
2006-09-06 9:11 ` Steven Smith
2006-09-06 15:56 ` Keir Fraser
2006-09-21 18:41 ` Markus Armbruster [this message]
2006-09-21 19:29 ` Keir Fraser
2006-09-21 19:33 ` Steven Smith
2006-09-10 7:39 ` Markus Armbruster
2006-09-10 9:38 ` Steven Smith
2006-09-30 8:52 ` Markus Armbruster
2006-11-02 10:10 ` Markus Armbruster
2006-11-02 10:36 ` Ewan Mellor
2006-11-02 12:34 ` Markus Armbruster
2006-11-02 16:19 ` Steven Smith
2006-11-02 16:31 ` Ewan Mellor
2006-11-03 14:18 ` Markus Armbruster
2006-11-03 17:01 ` Steven Smith
2006-11-02 15:02 ` Markus Armbruster
2006-11-02 15:38 ` Ewan Mellor
2006-11-02 7:53 ` Markus Armbruster
2006-11-02 7:58 ` Keir Fraser
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=874pv1m59y.fsf@pike.pond.sub.org \
--to=armbru@redhat.com \
--cc=Keir.Fraser@cl.cam.ac.uk \
--cc=aliguori@mail.utexas.edu \
--cc=katzj@redhat.com \
--cc=sos22@srcf.ucam.org \
--cc=xen-devel@lists.xensource.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.