Re: [Xen-devel] [PATCH] Paravirt framebuffer frontend kernel support [1/5]

[Steven Smith <sos22-xen@xxxxxxxxxxxxx>]

> > 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.
> 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.
If we're going to do this, it'd probably be worth exporting a backend
version number as well.

Even better would be having a bunch of separate feature flags, like we
do now for the different netif protocols.  You might, for instance,
have backends which can use grant tables export feature-large-grants
to their area of xenbus, and then have frontends notice that and set
request-large-grants in their area if they support it.  If the
relevant nodes aren't present, you conclude that the other end either
doesn't support the feature or doesn't want to use it for some reason.

This has a couple of advantages over a pure version number scheme:

-- If either end doesn't like the new protocol, it's trivial to make
   it fall back to the old one.  We might want to kill the old
   protocol eventually, but this at least makes the transition a bit
   easier.
-- You don't need to write any code now.
-- I think it's a bit cleaner than potentially artificially tying
   features together.

Thoughts?

Steven.

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel