From: Changlong Xie <xiecl.fnst@cn.fujitsu.com>
To: Eric Blake <eblake@redhat.com>,
Anthony PERARD <anthony.perard@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
zhanghailiang <zhang.zhanghailiang@huawei.com>,
Juan Quintela <quintela@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
qemu devel <qemu-devel@nongnu.org>,
Amit Shah <amit.shah@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v5 1/1] Introduce "xen-load-devices-state"
Date: Fri, 3 Jun 2016 11:07:57 +0800 [thread overview]
Message-ID: <5750F48D.90509@cn.fujitsu.com> (raw)
In-Reply-To: <5750E7AC.7040207@cn.fujitsu.com>
On 06/03/2016 10:13 AM, Changlong Xie wrote:
> On 06/03/2016 09:45 AM, Eric Blake wrote:
>> On 06/02/2016 07:26 PM, Changlong Xie wrote:
>>
>>>>> +
>>>>> + ioc = qio_channel_file_new_path(filename, O_WRONLY | O_CREAT,
>>>>> 0660, errp);
>>>>
>>>> This does not look right, it looks like it's going to open the file
>>>> to write to it. You probably want O_RDONLY, also I don't think the
>>>> O_CREAT flag is needed. (and without O_WRONLY, mode can be 0 instead of
>>>> 0660.)
>>>>
>>>
>>> Yes, as you said. We should use 0_RDONLY for open(2), so mode should
>>> be 0.
>>
>> Huh? mode doesn't affect the current fd, but DOES affect the next
>> person to open the file. If you are truly creating the file, then a
>> mode of 0 means you won't be able to reopen it without chmod. And if
>> you are doing O_RDONLY | O_CREAT, all you will be able to create is an
>> empty file, which is a pretty boring read. So drop the O_CREAT, and
>> then you don't need a mode argument at all.
>>
>
> Yes, i just mean qio_channel_file_new_path(filename, O_RDONLY, 0, errp)
I just notice that, qemu specifies flag 'O_BINARY' to allow system to
differentiate between a text file and a binary file( I guess so?). For
backward compatibility, refer to function test_io_channel_file(), i will
use
qio_channel_file_new_path(filename, O_RDONLY | O_BINARY, 0, errp)
here.
> here. Maybe my poor english make you confused :(
>
> Thanks
> -Xie
>
>
>
>
next prev parent reply other threads:[~2016-06-03 3:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-02 10:36 [Qemu-devel] [PATCH v5 0/1] Introduce "xen-load-devices-state" Changlong Xie
2016-06-02 10:36 ` [Qemu-devel] [PATCH v5 1/1] " Changlong Xie
2016-06-02 15:14 ` Anthony PERARD
2016-06-03 1:26 ` Changlong Xie
2016-06-03 1:45 ` Eric Blake
2016-06-03 2:13 ` Changlong Xie
2016-06-03 3:07 ` Changlong Xie [this message]
2016-06-03 1:56 ` Changlong Xie
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=5750F48D.90509@cn.fujitsu.com \
--to=xiecl.fnst@cn.fujitsu.com \
--cc=amit.shah@redhat.com \
--cc=anthony.perard@citrix.com \
--cc=armbru@redhat.com \
--cc=dgilbert@redhat.com \
--cc=eblake@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=sstabellini@kernel.org \
--cc=zhang.zhanghailiang@huawei.com \
/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.