[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] libxl: Use xenbus to communicate with xenstore if the socket fails
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. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |