From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NtjDp-0005zJ-5f for qemu-devel@nongnu.org; Mon, 22 Mar 2010 11:07:17 -0400 Received: from [199.232.76.173] (port=49244 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NtjDo-0005z7-QC for qemu-devel@nongnu.org; Mon, 22 Mar 2010 11:07:16 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NtjDm-00077C-Mc for qemu-devel@nongnu.org; Mon, 22 Mar 2010 11:07:16 -0400 Received: from dpc6682208002.direcpc.com ([66.82.208.2]:40809 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 1NtjDk-00076c-IW for qemu-devel@nongnu.org; Mon, 22 Mar 2010 11:07:14 -0400 Message-ID: <4BA785C8.5050702@third-harmonic.com> Date: Mon, 22 Mar 2010 10:59:20 -0400 From: john cooper MIME-Version: 1.0 Subject: Re: [Qemu-devel] virtio block device and sysfs References: <20100321161638.GA4174@shareable.org> <4BA70D83.4070806@third-harmonic.com> <20100322124224.GG30984@torres.zugschlus.de> In-Reply-To: <20100322124224.GG30984@torres.zugschlus.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marc Haber Cc: john cooper , john cooper , qemu-devel@nongnu.org Marc Haber wrote: > Hi, > > On Mon, Mar 22, 2010 at 02:26:11AM -0400, john cooper wrote: >> This is a tad ironic as that is how this saga begun. Namely stuffing >> 20 bytes of serial number string into the virtio-blk PCI config space >> on qemu's side and pushing it over to the guest driver. I exposed this >> to the guest app via a new ioctl cmd which itself was the original >> point of contention. Someone took issue with introducing a new >> interface citing the existence of ATA and SCSI counterparts. However >> dragging in the associated baggage in order to emulate those interfaces >> unintentionally bloated usage of the config space to the point of breakage. >> To address this I'd moved from using config space to an unused BAR which >> (understandably) didn't go over too well. Somewhere along the line Rusty >> posted a minimal alternative version which directly used a virtio request >> to retrieve the data from qemu which is arguably the right way to do the >> job. > > *argh* That sounds like politics. Well, maybe. But it is hard to argue with anyone calling the ATA_IDENTIFY interface ugly -- it is. Concerning qemu->virtio_blk communication, I don't think an argument to use PCI config space exists after one looks at the implementation of adding a new virtio request. >> That said we still had a dispute over what interface would be used to >> pass the S/N back to the guest: a new interface or reuse of an existing >> interface (eg: ATA IDENTIFY). That's where things fizzled when we >> couldn't immediately resolve the issue. So publishing the S/N in >> /sys would seem to side step this snag. > > Re-using an existing interface would probable make it easier for > non-Linux OSses to also take advantage of this, since their ATA driver > is already there. Exactly my singular motivation and honestly the only redeeming quality of propagating that crusty interface. >> I could have swore I sent out a guest-driver-app-interface-less >> version of the patch using virtio to pass the S/N but didn't find it in >> the archives. I did however locate it and can bring it forward as a >> reference for the above if interest exists. > > If it brings the issue forward and gives me hope to be able to do what > I want to do in a reasonable time frame, why not. Just time. But I'll resurrect the patch so we don't have to go through all of this again. -john -- john.cooper@third-harmonic.com