Re: [Qemu-devel] [RESEND][PATCH 3/9] microdrive: qdevify

[andrzej zaborowski <balrogg@gmail.com>]

On 17 May 2011 07:44, Jan Kiszka <jan.kiszka@web.de> wrote:
> On 2011-05-17 03:38, andrzej zaborowski wrote:
>> On 16 May 2011 15:08, Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> wrote:
>>> On 5/16/11, andrzej zaborowski <balrogg@gmail.com> wrote:
>>>> On 16 May 2011 06:54, Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> 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), 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