On Wed, Oct 30, 2013 at 5:51 PM, Laszlo Ersek <ler...@redhat.com> wrote: > On 10/31/13 00:26, Jordan Justen wrote: > >>> Jordan, could you please explain the problem again? >> >> 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. >> 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? By the way, I'm also not sure about the virtio protocol being required at all here. Can't we also argue that the fundamental issue is that UEFI doesn't have a suitable IO protocol layer for non-PCI devices? (Which brings us, unfortunately, back to the UEFI spec...) Tangentially, the deprecated (?) MdePkg/Include/Protocol/DeviceIo.h confuses me. Did it make pci-cfg optional? Why was it deprecated? I'm thinking Andrew or Mike could give me a history lesson here. :) -Jordan ------------------------------------------------------------------------------ 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
