Re: [Xen-devel] [edk2] [RFC] Introduting Xen PV block driver to OVMF

[Jordan Justen <jljusten@xxxxxxxxx>]

On Tue, May 20, 2014 at 8:11 AM, Anthony PERARD
<anthony.perard@xxxxxxxxxx> wrote:
> Hi all,
>
> I've been working on writing a driver to use a Xen PV disk directly from
> OVMF.  So far, I have a working prototype, a guest can boot from a PV
> device.  The code can be found on a git repo:
> git://xenbits.xen.org/people/aperard/ovmf.git  pv-disk
> (http://xenbits.xen.org/gitweb/?p=people/aperard/ovmf.git;a=summary)

Would this be contributed under the MIT license?

Generally, for simplicity we try to just use BSD licensed code in the
tree. But, it does seem that there are exceptions:
* AppPkg/Applications/Python/Python-2.7.2/LICENSE
* FatBinPkg/License.txt

> (I don't want to send yet the patchs to the mailing list since there is
> lots of dead code and probably hard to read because of the absence of
> coding style)
>
> I would like your comment on the current design choice.
>
> What I have:
>   - Ovmf/XenbusDxe:
>   This driver is the first to start, based on the presence of a PCI
>   device, which will initialize plenty of stuff needed to access a PV
>   device and discover every PV devices.
>   It initializes the Grant Table and Xenstore.
>   It provide XenbusProtocol to PV drivers.
>   There are some hypercall, in assembly which will target GCC for now.
>
>   It consumes PciIoProtocol.
>   It provides XenbusProtocol.
>
>   - Ovmf/XenPvBlkDxe:
>   This is a block driver that use XenbusProtocol and provide BlockIO.
>   Everything that the driver need go through the XenbusProtocol, which
>   is Xenstore read/write, event channel initialization, Grant table
>   access.
>
>   - OvmfPkg/Include/IndustryStandard/Xen:
>   This contains all the public includes from Xen Project. There are
>   few modification to use function provided by Ovmf instead of POSIX
>   one.
>
>
> What are all this?
>   - Xenstore: it's a key/value database.
>   - Xenbus: It's a king a bus that is bluild on top of Xenstore, this is
>     used to discover PV devices.
>   - Event Channel: It provide event notification between the two sides
>     of a PV devices, the frontend and backend. This normaly is an
>     interrupt.
>   - Grant Tables: To grant access to part of a guest memory to another
>     guest.
>
>
> Do I need to apply the coding style to the public includes that come
> from Xen (which are store in Include/IndustryStandard)? I mean changing
> all uint32_t to UINT32, change every struct name, ...
> I will however comply to the coding style in Ovmf/XenbusDxe and
> XenPvBlkDxe.

If the code will be shared by another project, then keeping the
original code style can be considered to help with future merging. You
might want to consider separating the EDK II specific code into
separate files which can use the EDK II code style wherever possible.

An example of a file that does not use the EDK II code style:
OvmfPkg/Include/IndustryStandard/LinuxBzimage.h

> I'm not sure what I should do with the assembly code, is writing it for
> GCC enough or should I use another format (.S + .asm)?

Currently we need both .S and .asm. Hopefully this will motivate you
to keep the assembly code as small as possible. :)

-Jordan

>
> Regards,
>
> --
> Anthony PERARD
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel