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
|
Home