From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O53Nk-0006xB-OA for qemu-devel@nongnu.org; Thu, 22 Apr 2010 16:52:20 -0400 Received: from [140.186.70.92] (port=55772 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O53Nj-0006wm-JM for qemu-devel@nongnu.org; Thu, 22 Apr 2010 16:52:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O53Ni-00067D-53 for qemu-devel@nongnu.org; Thu, 22 Apr 2010 16:52:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1528) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O53Nh-000670-Tg for qemu-devel@nongnu.org; Thu, 22 Apr 2010 16:52:18 -0400 Message-ID: <4BD0B61A.4000800@redhat.com> Date: Thu, 22 Apr 2010 16:48:26 -0400 From: john cooper MIME-Version: 1.0 Subject: Re: [Qemu-devel] virtio block device and sysfs References: <20100306224234.GA1145@torres.zugschlus.de> <4B96BECF.2000505@codemonkey.ws> <20100322123816.GF30984@torres.zugschlus.de> <4BA77D16.90001@redhat.com> <20100422203055.GF5321@torres.zugschlus.de> In-Reply-To: <20100422203055.GF5321@torres.zugschlus.de> Content-Type: text/plain; charset=UTF-8 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@redhat.com, Rusty Russell , qemu-devel@nongnu.org Marc Haber wrote: > Hi, > > On Mon, Mar 22, 2010 at 10:22:14AM -0400, john cooper wrote: >> Marc Haber wrote: >>> It the serial "number" can be alphanumeric, that would be great to have. >> It is simply a string of 20 characters, which AFAICT has >> its roots in the ATA S/N convention along with many other >> puzzling present day evils. > > That would be enough for my purposes, but more would be acceptable as > well. Internally the s/n string is currently limited to 20 bytes. >> All that said, I like the alternate choice of adding a >> special virtio request far better. It is actually simpler >> (and more maintainable IMO) than going through the >> gyrations of stuffing the S/N data through PCI config >> space. > > Whatever is more easily implemented ;) How would a Windows > installation see the label then? Unknown at this point. That was part of my earlier motivation to package up this information as an ATA_IDENTIFY command which AFAIK is digestible by windows. > Has my wish made its way on the official wishlist and/or roadmap? I submitted a virtio-based patch a few weeks ago. I'd been waiting for a reply from you concerning the /sys support you'd mentioned. If that plan has fallen by the wayside I'll forward a more robust ioctl patch to Rusty so we can tie this off. -john -- john.cooper@redhat.com