From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v2] libxenstore: prefer using the character device Date: Tue, 1 Sep 2015 13:03:27 +0100 Message-ID: <1441109007.27618.55.camel@citrix.com> References: <55D2FF72.7050006@citrix.com> <1440684278-16838-1-git-send-email-jonathan.creekmore@gmail.com> <20150827165643.GU22586@zion.uk.xensource.com> <21983.20700.957792.401545@mariner.uk.xensource.com> <55E03089.7080009@citrix.com> <21989.35784.590403.428570@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZWkHo-0004EG-45 for xen-devel@lists.xenproject.org; Tue, 01 Sep 2015 12:03:36 +0000 In-Reply-To: <21989.35784.590403.428570@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson , David Vrabel Cc: Jonathan Creekmore , Wei Liu , xen-devel@lists.xenproject.org, stefano.stabellini@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On Tue, 2015-09-01 at 12:28 +0100, Ian Jackson wrote: > 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 ? It was added by 2fb3683e7b164ee2b324039f7c9d90fe5b1a259b, which looks to be circa 3.2ish (git describe --contains gave me a stupid answer, so not sure when it actually hit mainline, 3.2-rc was in Makefile at that commit). It's perhaps nearly time but I don't think we can quite discard e.g. 3.0 yet and I'm not sure of the status of the forwarded ported classic Xen kernels. BTW around the same time /dev/xen/foo replacements were added for most /proc/xen functionality, e.g. privcmd and xenbus_backend (replacing two xsd_* I think). Really we ought to be moving over. > > > > > + 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. I've done so, with my Ack as well. thanks. Ian.