On 11/08/13 19:48, Jordan Justen wrote: > On Wed, Oct 30, 2013 at 5:51 PM, Laszlo Ersek <ler...@redhat.com> wrote: >> On 10/31/13 00:26, Jordan Justen wrote: >> >>> This protocol interface doesn't seem to follow the conventions of the >>> other io protocols. In addition, the alignment issue seems unresolved >>> to me. >>> >>> I just don't want any code outside of EDK II to pick this interface >>> up, and become dependent on it. >>> >>> Changing the width to be enum based, and omitting 64-bit accesses >>> seems to resolve my immediate concerns. >> >> I think that changing the width to be enum based would eliminate a >> safety feature of the (device specific) VIRTIO_CFG_READ() macros -- we >> could no longer check if the size of the pointer target, and the size of >> the device-specific field, are equal. The driver writer would have to >> specify the field width (the enum) each time. I think that's more >> brittle than what we have now. > > It seems like a matter of preference. I'm not a huge fan of the enum > width in PciIo/CpuIo, but I'd rather just do things the 'UEFI way' for > consistency.
No objection on my part. >>> I would also accept adding a disclaimer comment in the protocol file, such >>> as: >>> "This protocol is a work in progress, and should not be used outside >>> of the EDK II tree." >>> Unfortunately, I think it would be all to easy to miss such a disclaimer. >> >> This is positively how I've approached the new protocol. In my eyes it's >> nothing to standardize or advertise or whatever. It's only a protocol >> because that's how we implement virtual functions (a structure of >> function pointers) in UEFI, while remaining compatible with the driver >> model (automatic discovery etc). That's all. >> >> The protocol serves our direct needs. We have two implementations, and >> three clients. I don't believe in early generalization. > > It seems like there is a fair amount of interest in virtio. Can we at > least make it clear that this protocol interface is only half-baked, > and therefore should not be widely relied upon? Yes, we should add such a disclaimer. I guess people trying to use the protocol would look up the struct definition with the members, so that's probably a good place. (This is what you suggested too, in my understanding.) Thanks, Laszlo ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
