From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MshnJ-0002Xg-BX for qemu-devel@nongnu.org; Tue, 29 Sep 2009 14:51:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MshnF-0002XR-Tt for qemu-devel@nongnu.org; Tue, 29 Sep 2009 14:51:25 -0400 Received: from [199.232.76.173] (port=59693 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MshnF-0002XO-PK for qemu-devel@nongnu.org; Tue, 29 Sep 2009 14:51:21 -0400 Received: from dpc6682208002.direcpc.com ([66.82.208.2]:40491 helo=anvil.third-harmonic.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MshnD-00007u-Qe for qemu-devel@nongnu.org; Tue, 29 Sep 2009 14:51:21 -0400 Message-ID: <4AC25599.1090400@third-harmonic.com> Date: Tue, 29 Sep 2009 14:44:41 -0400 From: john cooper MIME-Version: 1.0 References: <4AB7A01A.3000206@redhat.com> <4AB8992B.7070709@redhat.com> <4AB8DD53.7070806@redhat.com> <4AB8DECA.3090908@redhat.com> <4AB8E88C.4040103@redhat.com> <4AB980E6.2070203@codemonkey.ws> <4AB9AA8E.7060800@third-harmonic.com> <4AC1A49A.1010308@redhat.com> <20090929065856.GC25389@redhat.com> <4AC1B5CD.7050702@redhat.com> <20090929085450.GE25389@redhat.com> <4AC211C8.1060202@codemonkey.ws> In-Reply-To: <4AC211C8.1060202@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 0/2] fix virtio_blk serial pci config breakage List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "Michael S. Tsirkin" , john cooper , Rusty Russell , qemu-devel@nongnu.org, Avi Kivity , jens.axboe@oracle.com, Vadim Rozenfeld Anthony Liguori wrote: > 2) Passing an ATA identity page is goofy. We should just pass the > serial number and let Linux generate the identity page. I have a hard time disagreeing with that comment. But the rationale that got us here was from the user's perspective this information could be trivially exposed via a preexisting interface vs. creating a new interface as I'd done initially. It was also pointed out other defined fields in the identify page exist which were potentially useful. So pressing a HDIO_GET_IDENTITY ioctl into service here didn't seem unreasonable. In terms of getting that bag of bits from qemu to the guest userspace, having qemu cobble together the page is arguably appropriate as that it where the source of the information resides. The alternative of pushing knowledge of this structure into the guest driver seems unnatural. Moreover we would still somehow need a means to get the data from qemu to the driver even if the driver was only packaging it up for export as an identify page. > Just because > Linux requires this as it's user space interface, that doesn't mean that > other guests will (like Windows). Instead of exposing an opaque blob, > we should expose the information we need in a structured way. The identify page is defined as the return of an "identify drive" command from an ATA drive/controller. I'd hazard it is a familiar structure in a windows driver/userland context as well. -john -- john.cooper@third-harmonic.com