From: "Daniel P. Berrange" <berrange@redhat.com>
To: Fam Zheng <famz@redhat.com>
Cc: qemu-devel@nongnu.org, kwolf@redhat.com, qemu-block@nongnu.org,
jcody@redhat.com, mreitz@redhat.com, stefanha@redhat.com,
pbonzini@redhat.com
Subject: Re: [Qemu-devel] Block layer complexity: what to do to keep it under control?
Date: Wed, 29 Nov 2017 12:32:36 +0000 [thread overview]
Message-ID: <20171129123236.GC13499@redhat.com> (raw)
In-Reply-To: <20171129035502.GD8889@lemon>
On Wed, Nov 29, 2017 at 11:55:02AM +0800, Fam Zheng wrote:
> So in principle, what should we do to make the block layer easy to understand,
> develop with and debug? I think we have opportunities in these aspects:
>
> - Documentation
>
> There is no central developer doc about block layer, especially how all pieces
> fit together. Having one will make it a lot easier for new contributors to
> understand better. Of course, we're facing the old problem: the code is
> moving, maintaining an updated document needs effort.
>
> Idea: add ./doc/deve/block.txt?
When I was writing the LUKS block driver one of the bug problems I had was
understanding the internal BlockDriver APIs, as there's almost a complete
lack of any API documentation for them. So I would strongly like to see
inline API documentation in the header files to describe the APIs. eg more
of this:
commit b461151ff31c7925f271c297e8abed20231ac7d3
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Thu Aug 31 11:54:56 2017 +0100
block: document semantics of bdrv_co_preadv|pwritev
> More thoughts?
Currently the block driver layer has three different ways you can
implement the I/O path. bdrv_aio_{readv,writev}, bdrv_co_{readv,writev}
and bdrv_co_{preadv,pwritev}. This is pretty confusing to people who are
not core block maintainers, and doubtless increases the code complexity
to deal with three different I/O paths.
This is the usual curse of QEMU refactoring - a new framework is introduced
but only a few existing users are updated to use it. I'd suggest an
aggressive push to convert all block drivers to use the same internal APIs.
Set a deadline for maintainers to convert them, and if missed, drop the
drivers in question.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
prev parent reply other threads:[~2017-11-29 12:32 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-29 3:55 [Qemu-devel] Block layer complexity: what to do to keep it under control? Fam Zheng
2017-11-29 6:30 ` Jeff Cody
2017-11-29 12:16 ` Stefan Hajnoczi
2017-11-29 12:22 ` Paolo Bonzini
2017-11-29 12:00 ` Stefan Hajnoczi
2017-11-29 12:24 ` Paolo Bonzini
2017-11-29 13:24 ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2017-11-29 13:41 ` [Qemu-devel] " Kevin Wolf
2017-11-29 19:58 ` Dr. David Alan Gilbert
2017-11-30 9:47 ` Fam Zheng
2017-11-30 14:19 ` Stefan Hajnoczi
2017-12-01 10:16 ` Fam Zheng
2017-12-01 14:08 ` Stefan Hajnoczi
2017-12-01 15:00 ` Fam Zheng
2017-12-01 17:03 ` Paolo Bonzini
2017-12-01 19:03 ` Peter Maydell
2017-12-04 10:41 ` Stefan Hajnoczi
2017-12-01 19:27 ` Eric Blake
2017-12-04 10:16 ` Stefan Hajnoczi
2017-12-04 10:32 ` Peter Maydell
2017-11-29 12:32 ` Daniel P. Berrange [this message]
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=20171129123236.GC13499@redhat.com \
--to=berrange@redhat.com \
--cc=famz@redhat.com \
--cc=jcody@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.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.