From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44919) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMIX2-0006Uc-WF for qemu-devel@nongnu.org; Tue, 17 May 2011 07:33:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMIX1-0002Dv-Ms for qemu-devel@nongnu.org; Tue, 17 May 2011 07:33:44 -0400 Received: from thoth.sbs.de ([192.35.17.2]:20202) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMIX1-0002DG-EL for qemu-devel@nongnu.org; Tue, 17 May 2011 07:33:43 -0400 Message-ID: <4DD25D12.7030903@siemens.com> Date: Tue, 17 May 2011 13:33:38 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1303722395-10791-1-git-send-email-dbaryshkov@gmail.com> <1303722395-10791-3-git-send-email-dbaryshkov@gmail.com> <4DD20B20.1050403@web.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RESEND][PATCH 3/9] microdrive: qdevify List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: andrzej zaborowski Cc: Dmitry Eremin-Solenikov , qemu-devel@nongnu.org On 2011-05-17 13:08, andrzej zaborowski wrote: > 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 wrote: >>>> On 5/16/11, andrzej zaborowski wrote: >>>>> On 16 May 2011 06:54, Dmitry Eremin-Solenikov wrote: >>>>>> Socket is required, as we have to know the QBus before creating the >>>>>> device on it. >>>>> >>>>> Let's skip the qbusification then. It 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? I 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 from >>>> 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 cards >>>> 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. A major problem with qdev I see >>> now is that the creation and attachment of a device are one event >>> instead of two, which is the case for pcmcia. So 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) I haven't looked at the details of this particular issue, but from 10000 meters I do not yet understand how qdev prevents this. Do we lack addressability via qdev for these sockets? Then that would have to be fixed. >, 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). Even in the SoC domain, I did not come across any set of "memory mappings" that could not reasonably be abstractable to a device, thus could be wrapped by qdev. That there is usually no chip containing such a device in reality does not mean you can't and shouldn't handle it as an abstract one, encapsulating separate functions in a more complex chip. > 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. No longer having arbitrary, untraceable memory and io mappings but only well organized devices is a feature worth such shuffling. Usually that also offers the chance to clean up legacy code or complete half-done device models. We are good in inventing new APIs in QEMU, but so far we are not that successful getting rid of old ones. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux