From: "andrzej zaborowski" <balrogg@gmail.com>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qemu vl.c hw/omap.c
Date: Tue, 4 Dec 2007 02:28:15 +0100 [thread overview]
Message-ID: <fb249edb0712031728u15230c3hee1d0db3980fb804@mail.gmail.com> (raw)
In-Reply-To: <200712040120.26286.paul@codesourcery.com>
On 04/12/2007, Paul Brook <paul@codesourcery.com> wrote:
> On Tuesday 04 December 2007, andrzej zaborowski wrote:
> > On 04/12/2007, Paul Brook <paul@codesourcery.com> wrote:
> > > > Log message:
> > > > Always create an SD bdrv, so that PXA and OMAP boards can boot
> > > > with no card inserted again. Eventually SD, CDROM and floppy should
> > > > all be registered conditionally depending on machine.
> > >
> > > This seems the wrong way to solve this problem. The SD emulation should
> > > be able to cope with no device being present.
> >
> > The bdrv's represent the concept of "drive" rather than "media", and
> > also in the case the bdrv must be present whenever there is a SD slot,
> > not an SD card (so that monitor command change and eject can be used).
> > I agree that not all machines have an SD slot, as not all machines
> > have a cd-rom drive or floppy drive.
>
> Right, but I think you're going in the wrong direction. Most scsi interfaces
> do support hotplug of devices. For USB mass storage the whole controller is
> hotplug. Pre-allocating all possible devices simply doesn't scale.
We don't pre-allocate all possible devices, only the "drives" which
are integral part of the machine (as is the case of the SD slot in a
Zaurus, soldered to the PCB). New bdrv's can still be added and
removed in runtime for hotplugged devices and I have no intetion to
change that.
If you want to use the hotplugging-like mechanism for inserting
removable media like SD, CD or floppy, that would mean scrapping the
whole bdrv_is_removable(), bdrv_is_inserted(), bdrv_media_changed()
api.
Regards
next prev parent reply other threads:[~2007-12-04 1:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-04 0:10 [Qemu-devel] qemu vl.c hw/omap.c Andrzej Zaborowski
2007-12-04 1:02 ` Paul Brook
2007-12-04 1:11 ` andrzej zaborowski
2007-12-04 1:20 ` Paul Brook
2007-12-04 1:28 ` andrzej zaborowski [this message]
2007-12-04 9:28 ` Laurent Vivier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fb249edb0712031728u15230c3hee1d0db3980fb804@mail.gmail.com \
--to=balrogg@gmail.com \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).