All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Vasiliy G Tolstov <v.tolstov@selfip.ru>,
	"Xen-Devel (xen-devel@lists.xensource.com)"
	<xen-devel@lists.xensource.com>,
	tmem-devel@oss.oracle.com, Hackel <kurt.hackel@oracle.com>,
	Jan Beulich <JBeulich@novell.com>,
	Keir Fraser <keir.fraser@eu.citrix.com>,
	Kurt, stephen.spector@citrix.com,
	Chris Mason <chris.mason@oracle.com>
Subject: RE: [RFC] tmem ABI change... backwards compatibility unnecessary?
Date: Fri, 3 Sep 2010 07:47:20 -0700 (PDT)	[thread overview]
Message-ID: <04083d29-91f5-465c-953a-e8966df47cf5@default> (raw)
In-Reply-To: <4C80359C.5050002@goop.org>

> > Thank goodness ABI versioning was built into tmem from
> > the beginning!
> 
> Hm, I'm not really a big fan of having a single "ABI version".  It
> always seems better to have individual calls which can be
> augmented/replaced by new calls, and/or have capability flags to extend
> the ABI.  Versions mean you end up being stuck doing updates in a very
> coarse-grained way, and the long-term support gets very onerous.
> (Microsoft ABIs are a good antipattern to avoid, especially DirectX.)

While I agree in general, and tmem can cleanly handle other forms
of minor updates as well, this ABI version change was very nice
for this case where the ops data structure (passed to the hypercall
in memory) changed in size, thus changing the interface for most of
the critical tmem operations.

  reply	other threads:[~2010-09-03 14:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-01 14:36 [RFC] tmem ABI change... backwards compatibility unnecessary? Dan Magenheimer
2010-09-01 14:44 ` Vasiliy G Tolstov
2010-09-01 15:37   ` Dan Magenheimer
2010-09-01 15:04 ` Jan Beulich
2010-09-02 23:19   ` Dan Magenheimer
2010-09-02 23:39     ` Jeremy Fitzhardinge
2010-09-03 14:47       ` Dan Magenheimer [this message]
2010-09-01 16:46 ` Jeremy Fitzhardinge

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=04083d29-91f5-465c-953a-e8966df47cf5@default \
    --to=dan.magenheimer@oracle.com \
    --cc=JBeulich@novell.com \
    --cc=chris.mason@oracle.com \
    --cc=jeremy@goop.org \
    --cc=keir.fraser@eu.citrix.com \
    --cc=kurt.hackel@oracle.com \
    --cc=stephen.spector@citrix.com \
    --cc=tmem-devel@oss.oracle.com \
    --cc=v.tolstov@selfip.ru \
    --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.