From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NWrCX-0006VH-3j for qemu-devel@nongnu.org; Mon, 18 Jan 2010 07:59:25 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NWrCS-0006RW-74 for qemu-devel@nongnu.org; Mon, 18 Jan 2010 07:59:24 -0500 Received: from [199.232.76.173] (port=52150 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NWrCS-0006RH-3W for qemu-devel@nongnu.org; Mon, 18 Jan 2010 07:59:20 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38762) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NWrCR-0005pB-Hk for qemu-devel@nongnu.org; Mon, 18 Jan 2010 07:59:19 -0500 Message-ID: <4B545B22.5080605@redhat.com> Date: Mon, 18 Jan 2010 13:59:14 +0100 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC, PATCH 10/11] qdev: Add do_info_qbus and friends. References: <1261861899-1984-1-git-send-email-nathan@parenthephobia.org.uk> <1261861899-1984-11-git-send-email-nathan@parenthephobia.org.uk> <4B5439FF.7000309@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Nathan Baum , qemu-devel@nongnu.org On 01/18/10 13:34, Markus Armbruster wrote: >>> However, because there are both device properties and bus properties >>> (really: device properties common to all devices on this bus), their >>> names can clash. Device properties take precedence (see >>> qdev_prop_find()). Hmm, qdev_printf() prints even overridden bus >>> properties, not sure that's appropriate. Gerd? >> >> IMHO they must not clash. This isn't enforced in any way though. > > If they must not clash, then it makes no sense to invent a fancy prefix > to cope with clashes, I think. I've added the bus- and dev- prefixes to make clear where the properties come from (BusInfo or DeviceInfo) for informational purposes, not to avoid clashes. We could just drop that ... > Alternatively, we could declare devices overriding properties inherited > from the bus a feature. No, this is just asking for trouble IMHO. cheers, Gerd