All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent Hanquez <vincent.hanquez@eu.citrix.com>
To: Andre Przywara <andre.przywara@amd.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: future plans for libxl?
Date: Thu, 15 Apr 2010 08:42:44 +0100	[thread overview]
Message-ID: <4BC6C374.7030907@eu.citrix.com> (raw)
In-Reply-To: <4BC6BE62.3020000@amd.com>

On 15/04/10 08:21, Andre Przywara wrote:
> I stumbled upon missing 'info' support, so I implemented a basic version
> of it. A few questions about it:
> 1.) Is there a fixed interface for libxenlight? I see libxc interfaces
> duplicated (like {xc,libxl_get}_physinfo), is that thought to provide a
> more stable interface than xc does (which changed quite a bit lastly).
> What about extending this interface? For complete xl info I need more
> field of the physinfo sysctl to be provided by libxl_get_physinfo, is it
> OK to extend the struct libxl_physinfo?

yes, i've duplicated them for this exact purpose. it could work 
hand-in-hand with what i'm describing below.

for extending usually, you would just add a new field at the end of the
structure.

it's probably ok to extends the physinfo structure. however we tried
to separate some things that would be not very useful from a toolstack
point of view, compared to actually carrying all sorts of info of
questionable usefulness.

> 2.) I see a simple check of LIBXL_VERSION when doing libxl_ctx_init().
> Is that meant to be that hard or is a compatibility scheme planned
> (like: support apps using on older interface and somehow emulate it?)

it takes lots of resources to do a compat scheme. but eventually it 
could all be done with the LIBXL_VERSION check. if you upgrade
the library and something change, the previously compiled client
would still use a LIBXL_VERSION < compared to the current one in the 
library.

at this point, libxl could provide a mechanism to provide old -> new 
structure mechanism to provide automatic compatibilty with old 
userspace. note that it wouldn't cover function prototype change, but 
only structure change, and this is an extremly painful process
where you need to keep your old structure around, and have a 
(potentially) big fast switch case in function that need this compat layer.

it's much much simpler to just let client and library to be the exact 
same version, which is what the ctx_init function is doing at this point 
compared to the elaborate scheme of compat.

-- 
Vincent

  parent reply	other threads:[~2010-04-15  7:42 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-14  8:12 future plans for libxl? Andre Przywara
2010-04-14 15:48 ` Stefano Stabellini
2010-04-14 15:52   ` Paolo Bonzini
2010-04-14 16:00     ` Stefano Stabellini
2010-04-15  7:21   ` Andre Przywara
2010-04-15  7:26     ` David Markey
2010-04-15  7:48       ` Vincent Hanquez
2010-04-15 13:46       ` Ian Jackson
2010-04-15  7:42     ` Vincent Hanquez [this message]
2010-04-15  8:22       ` Andre Przywara
2010-04-15  9:35         ` Vincent Hanquez
2010-04-15 13:54           ` Ian Jackson
2010-04-15 13:53         ` Ian Jackson
2010-04-15 14:24           ` Vincent Hanquez
2010-04-15 14:25             ` Ian Jackson
2010-04-15 14:28               ` Vincent Hanquez
2010-04-15  9:41     ` Stefano Stabellini
2010-04-15 13:45     ` Ian Jackson
2010-04-16  9:04   ` Xu, Jiajun
2010-04-16 10:46     ` Ian Jackson
     [not found]       ` <4BC85C17.7070603@amd.com>
2010-04-16 16:25         ` Stefano Stabellini
2010-04-16 16:27         ` Ian Jackson
2010-04-16 16:59       ` Xu, Jiajun

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=4BC6C374.7030907@eu.citrix.com \
    --to=vincent.hanquez@eu.citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=Stefano.Stabellini@eu.citrix.com \
    --cc=andre.przywara@amd.com \
    --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.