From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34892) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sepkq-0007eq-UQ for qemu-devel@nongnu.org; Wed, 13 Jun 2012 11:45:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sepko-0008OD-Rv for qemu-devel@nongnu.org; Wed, 13 Jun 2012 11:45:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41467) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sepko-0008NA-Kc for qemu-devel@nongnu.org; Wed, 13 Jun 2012 11:45:06 -0400 Message-ID: <4FD8B57B.5000303@redhat.com> Date: Wed, 13 Jun 2012 17:44:59 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <4FD66B8F.4080203@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Semantics of DeviceState::realized and BlockDriverState List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Paolo Bonzini , =?ISO-8859-1?Q?Andreas_F=E4rber?= , qemu-devel , Anthony Liguori , Stefan Hajnoczi Am 13.06.2012 14:53, schrieb Markus Armbruster: > Anthony Liguori writes: >> Properties that affect file opening (flags and filename) cannot be >> changed after this point. Depending on the contents of the file, a >> backing_file property may be created after opened = true. The >> backing_file that gets created does *not* automatically have opened = >> true. A user explicitly needs to set that. >> >> This behavior is necessary to allow overriding backing files. > > Could you explain why we need to override backing files between open and > attach? > > Can you give another example of something we need to be able to do > between open and attach? It's just one example of an option that can get a default value from the image file, but can we overridden by the user (e.g. by libvirt in order to pass a file descriptor instead). The same is true for the backing file format, for an option whether QED mode may be used and probably quite a few more. > I'm not yet convinced. > > QOM design started with two states: unrealized and realized. > > For block backends, you suggest we need to split the unrealized state. > I'm not sure that's actually necessary. But even if it is, the result > still satisfies the unrealized/realized contract: > > 1. While unrealized, all you can do is set properties. Setting a > property may fail. > > 2. While realized, the object "can do stuff", but its properties are > typically immutable. > > Yes, that's a pretty vague contract. But TYPE_OBJECT is a pretty > abstract thing, so some vagueness may be unavoidable. If you can come > up with a tighter one, excellent. > > Note that a BDS satisfies 1. whether it's opened or not. There's a difference concerning which properties can be written. Initially you can write to all properties, after opening the image file some (like the filename) become read-only, and after attach/realize/whatever you call it more of them become read-only. Kevin