Hi, I had lost this topic for more than a few weeks...
On Mon, Mar 22, 2010 at 10:59:20AM -0400, john cooper wrote: > Marc Haber wrote: >> 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. Indeed. It was designed to interact with Hardware, not with software trying to look like hardware. > 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. Indeed. Frankly, I don't care too much about how the information is passed into the guest as long as the guest can read what the host said. (mis)using ATA data was only a naive approach since I know that there is an existing interface. If there is a better one, even better. >>> 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. But otoh, I will only use Linux on the guest side, and it is motivation for other developers to build a virtio driver for their favorite OS. >>> 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. Did that work? Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
