From: Stefano Stabellini <sstabellini@kernel.org>
To: Jan Beulich <JBeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
wei.liu2@citrix.com, George.Dunlap@eu.citrix.com,
andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com,
tim@xen.org, xen-devel@lists.xenproject.org
Subject: Re: [RFC] Xen PV Drivers Lifecycle
Date: Tue, 20 Dec 2016 15:09:55 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.10.1612201459360.13831@sstabellini-ThinkPad-X260> (raw)
In-Reply-To: <5858F122020000780012AC89@prv-mh.provo.novell.com>
On Tue, 20 Dec 2016, Jan Beulich wrote:
> >>> On 20.12.16 at 01:47, <sstabellini@kernel.org> wrote:
> > ## Design Phase
> >
> > The first step toward acceptance of a new PV protocol is to write a
> > design document and send it to xen-devel. It should cover the xenstore
> > handshake mechanism, the ABI, how the protocol works and anything else
> > which is required to write an implementation of it. The usage of C-like
> > structs to describe language and platform agnostic protocols is
> > discouraged.
> >
> > An attempt should be made for the protocol ABI to be backward compatible
> > and OS agnostic, but, realistically, backward and cross-platform
> > compatibility are not fully expected at this stage.
>
> How does backward compatibility matter for a new protocol? Is
> this perhaps rather about forward compatibility provisions
> (like requiring reserved fields to be zero to allow future use)?
By "backward compatibility" I mean promising that, in 5 years time, a
new frontend will still be able to connect to a backend written in 2016.
This level of support requires an understanding of the protocol and its
subtleties which usually only comes from experience. Hence, I am
suggesting to make this kind of promises only after the code has lived
in-tree for a while and has been subject to wider testing.
Maybe I should call it cross-versions compatibility?
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-12-20 23:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-20 0:47 [RFC] Xen PV Drivers Lifecycle Stefano Stabellini
2016-12-20 7:51 ` Jan Beulich
2016-12-20 23:09 ` Stefano Stabellini [this message]
2016-12-28 11:34 ` George Dunlap
2017-01-03 17:56 ` Stefano Stabellini
2017-01-04 11:15 ` Wei Liu
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=alpine.DEB.2.10.1612201459360.13831@sstabellini-ThinkPad-X260 \
--to=sstabellini@kernel.org \
--cc=George.Dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/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.