From: George Dunlap <george.dunlap@eu.citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
xen-devel@lists.xenproject.org,
Ian Campbell <Ian.Campbell@citrix.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
alex@alex.org.uk
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 [thread overview]
Message-ID: <52972D02.6070201@eu.citrix.com> (raw)
In-Reply-To: <21143.11087.826909.827676@mariner.uk.xensource.com>
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
next prev parent reply other threads:[~2013-11-28 11:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-26 11:42 [PATCH RESEND 0/1] libxl: introduce an option for disabling the non-O_DIRECT Ian Jackson
2013-11-26 11:42 ` [PATCH] libxl: introduce an option for disabling the non-O_DIRECT workaround Ian Jackson
2013-11-26 17:46 ` Konrad Rzeszutek Wilk
2013-11-26 17:56 ` George Dunlap
2013-11-26 18:18 ` Konrad Rzeszutek Wilk
2013-11-28 11:38 ` [PATCH] libxl: introduce an option for disabling the non-O_DIRECT workaround [and 1 more messages] Ian Jackson
2013-11-28 11:46 ` George Dunlap [this message]
2013-11-28 17:32 ` Ian Jackson
2014-04-02 12:26 ` Felipe Franciosi
2014-04-03 10:12 ` Stefano Stabellini
2014-04-03 10:51 ` Felipe Franciosi
2014-04-03 11:41 ` Ian Campbell
2014-04-03 12:53 ` Stefano Stabellini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52972D02.6070201@eu.citrix.com \
--to=george.dunlap@eu.citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=alex@alex.org.uk \
--cc=konrad.wilk@oracle.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.