[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC] Xen PV Drivers Lifecycle
On Wed, 28 Dec 2016, George Dunlap wrote: > On Tue, Dec 20, 2016 at 11:09 PM, Stefano Stabellini > <sstabellini@xxxxxxxxxx> wrote: > > On Tue, 20 Dec 2016, Jan Beulich wrote: > >> >>> On 20.12.16 at 01:47, <sstabellini@xxxxxxxxxx> 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? > > Right, so I think you mean that you design the (new) protocol such > that *future* versions can be backwards-compatible. > > What if you rephrase it something like the following? > > "An attempt should be made to design the ABI such that it will be OS > agnostic, that future versions will not need to introduce > backward-incompatible changes, and so on; but these are not yet hard > requirements." (Or perhaps, "not yet first-order goals.") sounds good to me _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |