[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |