From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46717) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzryN-0003OM-Kx for qemu-devel@nongnu.org; Tue, 21 Feb 2012 10:49:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RzryJ-0003jQ-L9 for qemu-devel@nongnu.org; Tue, 21 Feb 2012 10:49:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54642) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzryJ-0003jF-EZ for qemu-devel@nongnu.org; Tue, 21 Feb 2012 10:49:43 -0500 From: Markus Armbruster References: <73865e0ce364c40e0eb65ec6b22b819d@mail.gmail.com> <4F311BBA.8000708@codemonkey.ws> <4F312FD3.5020206@zerto.com> <4F3137DB.1040503@redhat.com> <4F3139CE.4040103@zerto.com> <4F314798.8010009@redhat.com> <4F3211D0.3070502@zerto.com> <4F323875.1000000@redhat.com> <4F3244C2.1040604@zerto.com> <4F32489A.80307@redhat.com> <4F32788C.60904@zerto.com> <4F40FBD6.2000500@zerto.com> <4F425987.20103@redhat.com> <4F435DD2.8080600@redhat.com> <4F4360C7.5080806@redhat.com> <4F4368BF.4040707@redhat.com> <4F436D76.6090206@redhat.com> <4F43773B.6060109@redhat.com> <4F4381CE.70604@redhat.com> Date: Tue, 21 Feb 2012 16:49:38 +0100 In-Reply-To: (Stefan Hajnoczi's message of "Tue, 21 Feb 2012 12:22:40 +0000") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] BlockDriverState stack and BlockListeners List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , =?utf-8?B?16rXldee16gg15E=?= =?utf-8?B?158g15DXldeo?= , =?utf-8?B?16LXldeT?= =?utf-8?B?15Mg16fXk9ed?= , Jeff Cody , dlaor@redhat.com, qemu-devel@nongnu.org, Zhi Yong Wu , Federico Simoncelli , Ori Mamluk , Yair Kuszpet , Paolo Bonzini Stefan Hajnoczi writes: > This is a good discussion because BlockDriverState has become bloated > and complex. A lot of fields only apply to sub-cases and we should > really split this struct. Yup. We've had discussions where couldn't even agree whether a specific block driver is a format or a protocol or something else entirely. This is because the code doesn't really make distinctions. > Fields like "backing_file" *should* be in generic code, not duplicated > in each Format. Debatable. > But BlockDriverState is too generic since it also > encompasses Protocols and Listeners. > > You mentioned that some of these classes would be "internal". I think > everything should be exposed in the QOM just like Linux exposes kernel > objects in sysfs. It makes troubleshooting and debugging easier. > > As has been pointed out, "Listener" suggests a passive role. Perhaps > BlockFilter, BlockProcessor, or BlockModule is a better name. BlockFilter sounds good to me. > Ideally Formats can be isolated from the rest of the block layer so > that it becomes easy to create a libimageformat. If we bake > coroutines, I/O APIs, and memory allocation functions too deeply into > Formats then they are hard to test and impossible to use outside of > QEMU. Wouldn't that be nice.