[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2] libxenstore: prefer using the character device



David Vrabel writes ("Re: [Xen-devel] [PATCH v2] libxenstore: prefer using the 
character device"):
> On 27/08/15 19:03, Ian Jackson wrote:
> > I confess I still see this as working around a kernel bug.  Only this
> > time we are switching from a buggy to non-buggy kernel interface.
> 
> /proc/xen/xenbus is deprecated.  The tools should use the non-deprecated
> interface.

Why don't we just change it, then ?  What kernels don't provide
/dev/xen/xenbus ?

> > Why don't we have the kernel provide only non-buggy interfaces ?
> 
> >>> + if (access("/dev/xen/xenbus", F_OK) == 0)
> >>> +         return "/dev/xen/xenbus";
> > 
> > Also, previously xs_domain_dev was a function which simply returned a
> > static value.  I feel vaguely uneasy at putting this kind of
> > autodetection logic here.
> 
> "Vaguely uneasy"?  Are we engineers or witchdoctors?

It doesn't fit my mental model of what this function is for.  I think
it would be in better taste would be to arrange to attempt to call
open() on both strings.  But perhaps that is too much to do at this
stage of the release.

> xs_domain_dev() already does a system call to query the environment so
> it did not just "return a static value":

getenv is not a system call.


Anyway, if others don't have similar objections I am not nacking
this.  It may be applied with Wei's ack.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.