From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34403 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OJpbe-0007Jo-99 for qemu-devel@nongnu.org; Wed, 02 Jun 2010 11:11:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OJpbZ-00033k-At for qemu-devel@nongnu.org; Wed, 02 Jun 2010 11:11:46 -0400 Received: from mail.codesourcery.com ([38.113.113.100]:35479) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OJpbY-000339-VS for qemu-devel@nongnu.org; Wed, 02 Jun 2010 11:11:41 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] Name the default PCI bus "pci.0" on all architectures Date: Wed, 2 Jun 2010 16:10:56 +0100 References: <1274287377-19424-1-git-send-email-berrange@redhat.com> <201005282039.53749.paul@codesourcery.com> <20100602141242.GA10992@redhat.com> In-Reply-To: <20100602141242.GA10992@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006021610.56493.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org > The problem is that the ID names of default devices in machines are ABI > sensitive. Management apps need to know what the ID of these default > devices are. The x86 machines have already used 'pci.0' as their name > in the previous 0.12 release and libvirt is using this naming. We later > discovered many non-x86 archs have a name of just 'pci'. We need a single > consistent naming across all arches, hence this patch whcih standardizes > on 'pci.0'. I think you'll find x86 qdev conversion is both incomplete and incorrect. Specifically i440fx_int breaks several abstraction boundaries. I raised this issue at the time, but was told this was only temporary, and would be fixed. x86 should be made to match the arches that have been converted properly. > The '.N' convention is used extensively in QEMU and is more > futureproof as & when QEMU supports multiple buses, without requiring > apps to use the more verbose device paths to ensure uniquness. I disagree. Anything that depends on device creation order is fundamentally broken. If you want to create globally unique user-friendly tags for devices or busses then that is a completely different problem, and should be done via explicit aliases. qemu currently has no concept of a "default bus". Paul