From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH] libxl: introduce an option for disabling the non-O_DIRECT workaround [and 1 more messages] Date: Thu, 28 Nov 2013 11:46:10 +0000 Message-ID: <52972D02.6070201@eu.citrix.com> References: <1385466151-21481-1-git-send-email-ian.jackson@eu.citrix.com> <1385466151-21481-2-git-send-email-ian.jackson@eu.citrix.com> <20131126174617.GM2959@phenom.dumpdata.com> <5294E0E6.1070305@eu.citrix.com> <20131126181850.GB2917@phenom.dumpdata.com> <21143.11087.826909.827676@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Vm032-0004p8-LZ for xen-devel@lists.xenproject.org; Thu, 28 Nov 2013 11:46:21 +0000 In-Reply-To: <21143.11087.826909.827676@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 , Konrad Rzeszutek Wilk , xen-devel@lists.xenproject.org, Ian Campbell , Stefano Stabellini , alex@alex.org.uk List-Id: xen-devel@lists.xenproject.org On 11/28/2013 11:38 AM, Ian Jackson wrote: > George Dunlap writes ("Re: [Xen-devel] [PATCH] libxl: introduce an option for disabling the non-O_DIRECT workaround"): >> Not everyone builds her own kernel from the latest release; until we can >> be relatively sure that this fix has hit distros (including older >> LTS-style ones), we have to deal with the fact that the O_DIRECT bug may >> be present. The purpose of this flag is to enable you to turn it on >> when you know it's safe -- for instance, if you're running a kernel with >> this changeset. >> >> It is worth asking the question now though: Given that this has been >> checked in, would it make sense to switch the polarity of this -- >> default to O_DIRECT on and have a flag to allow people to switch it off? > Surely if the kernel has been fixed, libxl should detect this and turn > off the workaround automatically. The kernel should expose something > that lets us tell. (If nothing else, we can use the version number, > although that's really not ideal.) Given how many bugs there are in the Linux kernel, it would seem rather unweildy to have a robust way of specifying if any individual one had been fixed for any given bug... -George