From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59679) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMI8I-0006Xi-7P for qemu-devel@nongnu.org; Tue, 17 May 2011 07:08:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMI8H-0006IU-66 for qemu-devel@nongnu.org; Tue, 17 May 2011 07:08:10 -0400 Received: from mail-pv0-f173.google.com ([74.125.83.173]:57276) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMI8G-0006IM-Ti for qemu-devel@nongnu.org; Tue, 17 May 2011 07:08:09 -0400 Received: by pvg3 with SMTP id 3so235670pvg.4 for ; Tue, 17 May 2011 04:08:07 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4DD20B20.1050403@web.de> References: <1303722395-10791-1-git-send-email-dbaryshkov@gmail.com> <1303722395-10791-3-git-send-email-dbaryshkov@gmail.com> <4DD20B20.1050403@web.de> Date: Tue, 17 May 2011 13:08:07 +0200 Message-ID: From: andrzej zaborowski Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RESEND][PATCH 3/9] microdrive: qdevify List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Dmitry Eremin-Solenikov , qemu-devel@nongnu.org On 17 May 2011 07:44, Jan Kiszka wrote: > On 2011-05-17 03:38, andrzej zaborowski wrote: >> On 16 May 2011 15:08, Dmitry Eremin-Solenikov wro= te: >>> On 5/16/11, andrzej zaborowski wrote: >>>> On 16 May 2011 06:54, Dmitry Eremin-Solenikov w= rote: >>>>> Socket is required, as we have to know the QBus before creating the >>>>> device on it. >>>> >>>> Let's skip the qbusification then. =C2=A0It seems that qbus is a wrong >>>> choice for pcmcia and there are no new features or bugs fixed by the >>>> conversion, it's code motion? =C2=A0I also don't see why the socket >>>> structure should be needed at the creation time of a PCI device for >>>> example, the BusInfo should be enough logically. >>> >>> Major point for qbus'ification was ability to create PCMCIA devices fro= m >>> command line/via other management tools. This would also allow us e.g. >>> to move microdrive driver to common ide parts, etc. >> >> That would be nice but it may be better to use separate command line >> switches / monitor commands for hotpluggable busses. >> >>> >>> For creation of a DeviceState via qdev_create you need BusState (which >>> is a part of PCMCIASocket). Of course I can make one global QBus for >>> all PCMCIA devices and make some artificial hacks to attach/detach card= s >>> to artificial sockets, but this seems like a hack. >> >> I considered that for a moment too but it's uglier than current code >> and doesn't achieve what you want, because the command line has no >> provision for triggering attachment. =C2=A0A major problem with qdev I s= ee >> now is that the creation and attachment of a device are one event >> instead of two, which is the case for pcmcia. =C2=A0So your patch tries = to >> merge these two events. > > What is the point of allowing the existence of unattached pcmcia > devices? I think there was similar discussion about usb to allow attach > detach without delete, but IIRC that was finally rejected as there is no > real benefit in avoiding full creation/destruction. It's more about being able to detach and re-attach (in the same socket or another), migrate, savevm/loadvm separately from the machine although this possibility is not used now anyway. I just think it's logical for a hotpluggable bus that this be possible and it's wrong to require the socket structure when creating a device, although I'll ack/push the patches if that's a general opinion. > > Keep in mind that there may be a day where we finally obsolete support > for non-qdev (or whatever it's name will be then) devices. Not allowing non-qdev devices would be difficult to do because a "device" is just a set of memory mappings and it's a fuzzy term altogether (in SoCs especially). What I'd like to avoid is shuffling a piece of code into an api it does not fit just because there's a trend to use it, you can burn cycles endlessly reordering code with no new features/bugs fixed. Cheers