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

[Jan Kiszka]

On 2011-05-17 13:08, andrzej zaborowski wrote:
> On 17 May 2011 07:44, Jan Kiszka <address@hidden> wrote:
>> On 2011-05-17 03:38, andrzej zaborowski wrote:
>>> On 16 May 2011 15:08, Dmitry Eremin-Solenikov <address@hidden> wrote:
>>>> On 5/16/11, andrzej zaborowski <address@hidden> wrote:
>>>>> On 16 May 2011 06:54, Dmitry Eremin-Solenikov <address@hidden> 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