From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46432) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T21VP-0007kG-Pt for qemu-devel@nongnu.org; Thu, 16 Aug 2012 10:57:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T21VO-00017V-NS for qemu-devel@nongnu.org; Thu, 16 Aug 2012 10:57:03 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:56217) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T21VO-000174-GO for qemu-devel@nongnu.org; Thu, 16 Aug 2012 10:57:02 -0400 From: Paul Brook Date: Thu, 16 Aug 2012 15:56:50 +0100 References: <1345124754-4173-1-git-send-email-peter.maydell@linaro.org> <871uj7diz7.fsf@blackfin.pond.sub.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <201208161556.52432.paul@codesourcery.com> Subject: Re: [Qemu-devel] [PATCH 0/3] Drop default SD card creation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Kevin Wolf , patches@linaro.org, Markus Armbruster , qemu-devel@nongnu.org > On 16 August 2012 15:11, Markus Armbruster wrote: > > Peter Maydell writes: > >> As suggested in the recent discussion on Markus' patchset to suppress > >> unused default drives, this patchset cleans up the omap and pxa2xx > >> > >> SD card controllers to behave like the other controllers: > >> * the init function looks for the next IF_SD drive > >> * if there isn't one, we start up as a controller with no card > >> > >> present > > > > Isn't this an incompatible change? Before, you get an SD card reader > > backed by an empty BDS default. You can load/unload cards in the > > monitor. After, you get an SD card reader that isn't backed by a BDS by > > default. Device models prepared for that can treat it as permanently > > empty. > > Hmm, yes, but most of our SD controllers already act that way. > We should probably fix them all... > > So what's the block layer equivalent of drive_get_next() that always > returns us something we can get a bdrv from? I think this may be the wrong way to fix this. SD cards aren't really have removable media. In the same way that a SCSI HDD are generally not removable media - you hotplug the whole drive. Don't we really want a proper QOM device for the SD card, with hotplug support. Paul