From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mr5UW-0007UU-70 for qemu-devel@nongnu.org; Fri, 25 Sep 2009 03:45:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mr5UR-0007U7-OT for qemu-devel@nongnu.org; Fri, 25 Sep 2009 03:45:19 -0400 Received: from [199.232.76.173] (port=50993 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mr5UR-0007U4-JJ for qemu-devel@nongnu.org; Fri, 25 Sep 2009 03:45:15 -0400 Received: from mx20.gnu.org ([199.232.41.8]:30023) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mr5UQ-0000iL-Rk for qemu-devel@nongnu.org; Fri, 25 Sep 2009 03:45:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mr5UQ-0007TG-37 for qemu-devel@nongnu.org; Fri, 25 Sep 2009 03:45:14 -0400 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8P7jCQa031514 for ; Fri, 25 Sep 2009 03:45:13 -0400 Message-ID: <4ABC7503.70200@redhat.com> Date: Fri, 25 Sep 2009 09:45:07 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 10/13] Implement scsi device destruction References: <1253611767-6483-1-git-send-email-kraxel@redhat.com> <1253611767-6483-11-git-send-email-kraxel@redhat.com> <8763b8b1dh.fsf@pike.pond.sub.org> In-Reply-To: <8763b8b1dh.fsf@pike.pond.sub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org 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? >> +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 ;) cheers, Gerd