From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:56001)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1RSovl-0002yy-0J
	for qemu-devel@nongnu.org; Tue, 22 Nov 2011 06:54:33 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1RSovg-0001P4-KI
	for qemu-devel@nongnu.org; Tue, 22 Nov 2011 06:54:28 -0500
Received: from mail-ww0-f53.google.com ([74.125.82.53]:51964)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1RSovg-0001Os-DF
	for qemu-devel@nongnu.org; Tue, 22 Nov 2011 06:54:24 -0500
Received: by wwf27 with SMTP id 27so143374wwf.10
	for <qemu-devel@nongnu.org>; Tue, 22 Nov 2011 03:54:23 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <4ECB87E8.3030806@in.ibm.com>
References: <20111111064707.15024.69847.sendpatchset@skannery.in.ibm.com>
	<20111111064833.15024.54047.sendpatchset@skannery.in.ibm.com>
	<CAJSP0QVzx8hjLLCY1kXOaPxn-8DoN7NVLwP1eySD_yn2kZnXfw@mail.gmail.com>
	<4ECA447A.40500@in.ibm.com> <4ECB6F43.8060000@in.ibm.com>
	<CAJSP0QVMUbWdss25=HV-8qBtgDuc8drUJckxgpVWzJiHju6-mA@mail.gmail.com>
	<4ECB87E8.3030806@in.ibm.com>
Date: Tue, 22 Nov 2011 11:54:23 +0000
Message-ID: <CAJSP0QWmzFGkAcy6PCqYGVDXdtR858dDqF6v43sM1OS1H3dHRg@mail.gmail.com>
From: Stefan Hajnoczi <stefanha@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [v9 Patch 6/6]Qemu: raw posix implementation of
 reopen functions
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: supriya kannery <supriyak@in.ibm.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Supriya Kannery <supriyak@linux.vnet.ibm.com>, Christoph Hellwig <hch@lst.de>, qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>

On Tue, Nov 22, 2011 at 11:30 AM, supriya kannery <supriyak@in.ibm.com> wro=
te:
> Stefan Hajnoczi wrote:
>>
>> On Tue, Nov 22, 2011 at 9:45 AM, supriya kannery <supriyak@in.ibm.com>
>> wrote:
>>
>>>
>>> supriya kannery wrote:
>>>
>>>>
>>>> Stefan Hajnoczi wrote:
>>>>
>>>>>
>>>>> On Fri, Nov 11, 2011 at 6:48 AM, Supriya Kannery
>>>>> <supriyak@linux.vnet.ibm.com> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> + =A0 =A0 =A0 =A0}
>>>>>> + =A0 =A0 =A0 =A0if ((flags & BDRV_O_NOCACHE)) {
>>>>>> + =A0 =A0 =A0 =A0 =A0 =A0raw_rs->reopen_state.reopen_flags |=3D O_DI=
RECT;
>>>>>> + =A0 =A0 =A0 =A0} else {
>>>>>> + =A0 =A0 =A0 =A0 =A0 =A0raw_rs->reopen_state.reopen_flags &=3D ~O_D=
IRECT;
>>>>>> + =A0 =A0 =A0 =A0}
>>>>>> + =A0 =A0 =A0 =A0ret =3D fcntl_setfl(raw_rs->reopen_fd,
>>>>>> raw_rs->reopen_state.reopen_flags);
>>>>>>
>>>>>>
>>>>>
>>>>> I wonder if this works on Solaris, FreeBSD, etc?
>>>>>
>>>>> Perhaps there needs to be a fallback to the missing "else" case
>>>>> below...
>>>>>
>>>>>
>>>>>
>>>>
>>>> ok. Will look into whether this will work on Solaris, FreeBSD etc..
>>>>
>>>>
>>>
>>> This should work for all non-win Oses.
>>> I have tested only in x86.
>>>
>>> #ifndef _WIN32
>>> /* Sets a specific flag */
>>> int fcntl_setfl(int fd, int flag)
>>> {
>>> =A0int flags;
>>>
>>> =A0flags =3D fcntl(fd, F_GETFL);
>>>
>>
>> Are you sure POSIX guarantees that O_DIRECT can be changed with
>> F_SETFL? =A0I didn't find any statement in the specification. =A0It is
>> possible that this code compiles but does not actually work on
>> non-Linux OSes. =A0Did you run tests?
>>
>
> I don't have FreeBSD and Solaris systems to use.
> Referred the following man page links to verify that O_DIRECT in these
> OSes can be changed using fcntl.
> http://fuse4bsd.creo.hu/localcgi/man-cgi.cgi?fcntl+2
> http://man-wiki.net/index.php/2:fcntl
> If anybody with these systems can confirm, that would be very helpful.

Cool, thanks for sharing.  The safest would be to do a F_GETFL
afterwards and fall back to unsafe reopen if it didn't work.

Stefan