WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] libxl: Use xenbus to communicate with xenstore i

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] libxl: Use xenbus to communicate with xenstore if the socket fails
From: Mihir Nanavati <mihirn@xxxxxxxxx>
Date: Fri, 10 Dec 2010 03:39:40 -0800
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Vincent Hanquez <Vincent.Hanquez@xxxxxxxxxxxxx>
Delivery-date: Fri, 10 Dec 2010 03:40:56 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1291980266.13966.4808.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AANLkTiketBP-qtBE6su=Wkob8FEvvcht+KZDEVm6iDKS@xxxxxxxxxxxxxx> <1291886276.13966.4612.camel@xxxxxxxxxxxxxxxxxxxxxx> <4D00AA19.30205@xxxxxxxxxxxxx> <1291890116.13966.4619.camel@xxxxxxxxxxxxxxxxxxxxxx> <4D00B53F.2020903@xxxxxxxxxxxxx> <1291894771.13966.4667.camel@xxxxxxxxxxxxxxxxxxxxxx> <AANLkTinT5sSYqhPqo0he5CvLub0a2QcE-JH5fosxKR8s@xxxxxxxxxxxxxx> <1291972065.13966.4699.camel@xxxxxxxxxxxxxxxxxxxxxx> <AANLkTi=tMMHc42NwJ6B9Yfk4YKeHPf3vpG86_zEOLD3D@xxxxxxxxxxxxxx> <1291974527.13966.4708.camel@xxxxxxxxxxxxxxxxxxxxxx> <AANLkTinr17peuHB8e-kYg=7dZpVW_Yo54JGQFvnUa-w2@xxxxxxxxxxxxxx> <1291975404.13966.4712.camel@xxxxxxxxxxxxxxxxxxxxxx> <AANLkTikERSjFEz9kqmUGwQcX7fQHZ=d6Mdt_-Sd9XTcj@xxxxxxxxxxxxxx> <1291977913.13966.4757.camel@xxxxxxxxxxxxxxxxxxxxxx> <AANLkTi=fkdJjJCK8m837wRUEYrNjK=UtiZbitMLubhXb@xxxxxxxxxxxxxx> <1291980266.13966.4808.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Sorry, that was rather confusing ;) Hope this reads better.

~M

On Fri, Dec 10, 2010 at 3:24 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
On Fri, 2010-12-10 at 11:10 +0000, Mihir Nanavati wrote:
> Is this one ok? Thanks!

The way the API information is now presented in xs.h isn't that orderly
or clear on what is deprecated. I think it would be better to add
"deprecated please use xs_open()" to each to the comment blocks before
the deprecated functions and to put xs_open and xs_close before those
functions, with a suitable comment block describing their use.

>
> ~M
>
> On Fri, Dec 10, 2010 at 2:45 AM, Ian Campbell
> <Ian.Campbell@xxxxxxxxxxxxx> wrote:
>         Thanks but please put the deprecation comment in the header
>         where
>         potential callers are mostly likely to see it.
>
>         Tiny nitpick: it should be "if (...)" not "if(...)".
>
>
>         On Fri, 2010-12-10 at 10:34 +0000, Mihir Nanavati wrote:
>         > Done.
>         >
>         > ~M
>         >
>         > On Fri, Dec 10, 2010 at 2:03 AM, Ian Campbell
>         > <Ian.Campbell@xxxxxxxxxxxxx> wrote:
>         >         On Fri, 2010-12-10 at 09:55 +0000, Mihir Nanavati
>         wrote:
>         >         > Fair enough - is this something like what you had
>         in mind?
>         >
>         >
>         >         Almost. You don't need two bits to encode the
>         boolean
>         >         writeable property
>         >         -- I reckon should just ditch XS_OPEN_READWRITE
>         since its the
>         >         default
>         >         and equivalent to the absence of XS_OPEN_READONLY.
>         The common
>         >         case
>         >         should be to pass flags == 0 and get a read+write
>         connection.
>         >
>         >         Ian.
>         >
>         >
>         >         >
>         >         > ~M
>         >         >
>         >         > On Fri, Dec 10, 2010 at 1:48 AM, Ian Campbell
>         >         > <Ian.Campbell@xxxxxxxxxxxxx> wrote:
>         >         >         On Fri, 2010-12-10 at 09:38 +0000, Mihir
>         Nanavati
>         >         wrote:
>         >         >         >
>         >         >         >
>         >         >         > On Fri, Dec 10, 2010 at 1:07 AM, Ian
>         Campbell
>         >         >         >
>         >         >
>         >         >         >         For future flexibility should we
>         consider
>         >         passing a
>         >         >         flags
>         >         >         >         argument and defining
>         "XS_OPEN_READONLY
>         >         1<<0"
>         >         >         instead of
>         >         >         >         having an ro argument?
>         >         >         >
>         >         >         > Sure, we could do it, but I'm not too
>         sure what
>         >         other modes
>         >         >         we could
>         >         >         > have for opening, let alone ones that
>         might be
>         >         used
>         >         >         simultaneously in
>         >         >         > a bit field ;)
>         >         >
>         >         >
>         >         >         There's no downside to using a flag field
>         now, even
>         >         if no
>         >         >         compelling use
>         >         >         cases come to mind right now and it might
>         avoid an
>         >         API change
>         >         >         in the
>         >         >         future.
>         >         >
>         >         >         One vague thought I had was that I
>         recently added a
>         >         >         "nonreentrant" flag
>         >         >         to libxc for use in language bindings
>         which like to
>         >         control
>         >         >         threading
>         >         >         themselves. Some sort of "no watches" flag
>         might be
>         >         useful in
>         >         >         the future
>         >         >         for similar reasons.
>         >         >
>         >         >         >         I don't suppose you feel like
>         running sed
>         >         over the
>         >         >         tree to
>         >         >         >         convert the
>         >         >         >         in tree users, do you ;-)
>         >         >         >
>         >         >         >
>         >         >         > Could do, but I'd rather we get the
>         interface
>         >         finalized
>         >         >         first ;)
>         >         >
>         >         >
>         >         >         Sure.
>         >         >
>         >         >         > Is there anything one specially needs to
>         take into
>         >         >         consideration when
>         >         >         > replacing them in the bindings?
>         >         >
>         >         >
>         >         >         I can't think of any -- try it and if it
>         isn't
>         >         obviously
>         >         >         broken it's
>         >         >         probably fine ;-)
>         >         >
>         >         >         Ian.
>         >         >
>         >         >
>         >         >
>         >         >
>         >
>         >
>         >
>         >
>
>
>
>



Attachment: libxenstore_domain.patch
Description: Text Data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>