Re: [Qemu-devel] [4367] Align file accesses with cache=off (Kevin Wolf, Laurent Vivier)

[Jamie Lokier <jamie@shareable.org>]

Kevin Wolf wrote:
> No, nobody mentioned the recursion problem.

Hmm.  I concede you're right in the sense that it was mentioned, but
on a different thread about QEMU AIO recently :-)

Message-ID: <20080403113128.GA17900@shareable.org>
Avi Kivity wrote:
> Long term we want to replace the recursion by queuing.
Ah yes.  Reminds me of a bug in a program of mine with asynchronous
sockets.
    <explanation of bug>
I learned a few lessons about async callbacks:
    <general advice>

> And you were talking about 
> problem with two different file descriptors for one file, not about the 
> fcntl solution. Ok, might also be that the hints were just not explicit 
> enough for me. ;-)

Following the paragraph about two file descriptors, there was:

>> I'm not sure if that works, though.  On some OSes, if a file has any
>> non-O_DIRECT open descriptor, all I/O is buffered ignoring the
>> O_DIRECT flag.  If both are allowed simultaneously, I'm not sure what
>> happens with cache-coherency between direct I/Os and buffered I/Os.

Not sure if that is quite the same thing :-)

I did miss that switching O_DIRECT on/off while AIOs are in flight on
that descriptor might be dodgy (implementation dependent), and that it
might not do the right things w.r.t. cohrency.

> But even if so, this is more of a general feeling about how patches are 
> handled and not only related to this patch.

I agree and have a similar feeling, though it's not a bad thing
provided the issues are actually noticed, which they do seem to be.  I
have the impression there are many people working on different
specific features and subsystems, but not so much on overall
architecture in a coordinated and "visionary" way.

Most of my issues with QEMU are the epic list of difficulties with
Microsoft guests (espcially when people send me images for a different
VM), the peculiar divergence between KVM and QEMU features, and the
awkwardness of the monitor/command line interface.  Since I'm not an
active code contributor, and those are to a great extent feature
requests or only debuggable by users, I keep those thoughts largely to
myself :-)

-- Jamie