From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42670) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaOGZ-00063e-UW for qemu-devel@nongnu.org; Tue, 24 Mar 2015 08:49:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YaOGV-0005yv-Tj for qemu-devel@nongnu.org; Tue, 24 Mar 2015 08:49:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37004) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YaOGV-0005yd-MK for qemu-devel@nongnu.org; Tue, 24 Mar 2015 08:49:03 -0400 From: Markus Armbruster References: <1427137790-27265-1-git-send-email-armbru@redhat.com> <55113AE7.1070506@redhat.com> Date: Tue, 24 Mar 2015 13:48:57 +0100 In-Reply-To: <55113AE7.1070506@redhat.com> (Paolo Bonzini's message of "Tue, 24 Mar 2015 11:22:31 +0100") Message-ID: <877fu68ssm.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH for-2.3 0/3] Contain drive_get() misuse List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: peter.maydell@linaro.org, peter.crosthwaite@xilinx.com, qemu-devel@nongnu.org, michael@walle.cc, edgar.iglesias@gmail.com, Andreas =?utf-8?Q?F=C3=A4rber?= Adding Andreas because he's the odd fixer for pc87312. Paolo Bonzini writes: > On 23/03/2015 20:09, Markus Armbruster wrote: >> Drives defined with if!=none are for board initialization to wire up. >> Board code calls drive_get() or similar to find them, and creates >> devices with their qdev drive properties set accordingly. >> >> Except a few devices go on a fishing expedition for a suitable backend >> instead of exposing a drive property for board code to set: they call >> driver_get() or drive_get_next() in their realize() or init() method. >> Wrong. >> >> We can't fix this in time for the release, so do the next best thing: >> contain the mistakes as far as possible so they don't become ABI: >> >> * Mark them all with suitable FIXME comments [PATCH 1] >> >> * sdhci-pci is new, set cannot_instantiate_with_device_add_yet to make >> it unavailable with -device [PATCH 2] >> >> * A few more aren't currently available with -device, set >> cannot_instantiate_with_device_add_yet to ensure they stay >> unavailable [PATCH 3] >> >> * Left alone: m25p80-generic and its derivatives, ssi-sd, pc87312 > > Maybe worth documenting as future incompatible changes? These machines > are not versioned, so it's not the end of the world to make things saner > if somebody comes and qdevifies the SD card. Two questions: what exactly is going to change, and where do we want to document it? On the former: Use of -drive if=floppy with onboard pc87312 (machine "prep") shouldn't be affected. Likewise for connecting onboard m25p80-generic derivatives with if=mtd drives, or onboard ssi-sd with if=sd. Weird usage similar to the one you caught in time for sdhci-pci (--drive if=sd --device sdhci-pci) would break. It's possible when the target has the device, and the machine type has a suitable bus. * pc87312 Depends on CONFIG_PC87312, set in {ppc,ppc64}-softmmu.mak. Requires an ISA bus. I believe "prep" is the only machine providing one. Adding a second one with --device seems unlikely to work (I didn't try). If that's correct, there's nothing to document. If Andreas agrees, I can set cannot_instantiate_with_device_add_yet for pc87312 now. * ssi-sd Depends on CONFIG_SSI_SD, set in arm-softmmu.mak. Requires an SSI bus. At least the following targets provide one: collie, highbank, lm3s6965evb, lm3s811evb, midway, xilinx-zynq-a9. Can't exclude use of --device ssi-sd. I guess we want to document that --device ssi-sd will at some point cease to auto-connect to the next available if=sd drive and require the usual drive property instead. Okay? * m25p80-generic Depends on CONFIG_SSI_M25P80, set in {arm,microblaze,microblazeel}-softmmu.mak. Requires an SSI bus. At least the ARM targets above provide one. Can't exclude use with --device. Document just like ssi-sd. [...] > Acked-by: Paolo Bonzini Thanks!