qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 10/13] Implement scsi device destruction


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 10/13] Implement scsi device destruction
Date: Fri, 25 Sep 2009 15:10:57 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)

Gerd Hoffmann <address@hidden> writes:

>   Hi,
>
>> If I understand this correctly, SCSI devices "overwrite": if you add a
>> new one with an existing SCSI ID, the old one gets disconnected
>> automatically.  Isn't that inconsistent with other buses?  PCI,
>> specifically.  Question applies before your patch already.
>
> Yes, this is correct.
> I've just maintained current behavior.
>
> To extend that question:  While playing with that I've noticed linux
> does not automagically find the a scsi disk hot-plugged in.  After
> reboot (and the scsi bus rescan triggered by that) it finds the
> disk. Reloading the driver module probably would have worked too.  We
> don't signal the guest in any way it got a new disk, so this isn't
> exactly surprising.  Is this just a emulation limitation?  Or a
> limitation of the emulated scsi host adapters?

What appens when you hotplug or just switch on a real SCSI device?  Does
Linux pick it up automatically?  Long ago when I last tried that, I
think I had to do a magic write to sysfs to make it look for the device.

>>> +static int scsi_qdev_exit(DeviceState *qdev)
>>> +{
>>> +    SCSIDevice *dev = DO_UPCAST(SCSIDevice, qdev, qdev);
>>> +    SCSIBus *bus = DO_UPCAST(SCSIBus, qbus, dev->qdev.parent_bus);
>>> +
>>> +    assert(bus->devs[dev->id] != NULL);
>>> +    if (bus->devs[dev->id]->info->destroy) {
>>> +        bus->devs[dev->id]->info->destroy(bus->devs[dev->id]);
>>> +    }
>>> +    bus->devs[dev->id] = NULL;
>>> +    return 0;
>>>   }
>>
>> You have scsi_qdev_exit() as qdev callback exit().  It does the generic
>> stuff, then runs the SCSIDevice callback destroy() for the specific
>> stuff.  Shouldn't the two callbacks be named the same, to make their
>> relation more obvious?
>
> I'm just using the existing callbacks and windup stuff correctly in
> the qdev_free() paths.  Make the naming more consistent would be
> useful indeed, but that is IMHO a job for a separate patch.  And we
> should agree on a naming convention first ;)

Fair enough.

Tasteful naming *is* important.




reply via email to

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