qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/5] qdev/compat: virtio-blk-pci 0.10 compatibi


From: Filip Navara
Subject: Re: [Qemu-devel] [PATCH 3/5] qdev/compat: virtio-blk-pci 0.10 compatibility.
Date: Thu, 9 Jul 2009 21:42:47 +0200

On Thu, Jul 9, 2009 at 8:20 PM, Michael S. Tsirkin<address@hidden> wrote:
> On Thu, Jul 09, 2009 at 05:09:41PM +0200, Gerd Hoffmann wrote:
>> On 07/09/09 16:52, Michael S. Tsirkin wrote:
>>>>       .compat_props = (CompatProperty[]) {
>>>> +        {
>>>> +            .driver   = "virtio-blk-pci",
>>>> +            .property = "class",
>>>> +            .value    = "0x0180", /* PCI_CLASS_STORAGE_OTHER */
>>>
>>> it seems annoying that we can't use the symbolic name. Ideas how to fix 
>>> this?
>>
>> We could add a special property type instead of using hex32.  Then we
>> can have a string <-> int mapping and use something like
>>
>>              .value = "storage-other",
>>
>> Not sure it is worth the trouble though.
>>
>>>> -
>>>> -    uint16_t vendor;
>>>> -    uint16_t device;
>>>> -    uint16_t subvendor;
>>>> -    uint16_t class_code;
>>>> -    uint8_t pif;
>>>
>>> Are the other fields unused? If yes can be a separate patch ...
>>
>> Yes, they are all unused to date.  This patch puts class_code into use.
>>
>>>> +    if (proxy->class_code != PCI_CLASS_STORAGE_SCSI&&
>>>> +        proxy->class_code != PCI_CLASS_STORAGE_OTHER)
>>>> +        proxy->class_code = PCI_CLASS_STORAGE_SCSI;
>>>> +
>>>
>>> what does this do?
>>
>> Make sure proxy->class_code has one of the two allowed values.
>>
>>>>       vdev = virtio_blk_init(&pci_dev->qdev);
>>>>       virtio_init_pci(proxy, vdev,
>>>>                       PCI_VENDOR_ID_REDHAT_QUMRANET,
>>>>                       PCI_DEVICE_ID_VIRTIO_BLOCK,
>>>> -                    PCI_CLASS_STORAGE_OTHER,
>>>> -                    0x00);
>>>> +                    proxy->class_code, 0x00);
>>>>   }
>>>>
>>>>   static void virtio_console_init_pci(PCIDevice *pci_dev)
>>>
>>> does this mean that virtio block was broken by some previous
>>> patch? It's not a good way to split changes: bisecting won't work.
>>
>> Huh?  virtio block wasn't broken.  What makes you think it was?
>>
>> cheers,
>>   Gerd
>
> This is adding a parameter to a function. Before this patch it was missing
> this parameter so was broken?
>
It is not! Two parameters removed, two added.

F.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]