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

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Tue, Jun 03, 2014 at 04:02:16PM -0700, Jordan Justen wrote:
> 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?

I think most of the code source I am using is under BSD license. It
comes from FreeBSD and MiniOS (xen.git/extras/mini-os, which is likely
to be compatible with BSD).

> 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

That's good to know. I will keep the original coding style for the
includes then, they will live under
OvmfPkg/Include/IndustryStandard/Xen. That will definitely help future
merge to gain new features.

> > 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. :)

OK, I will provide .S and .asm when assembly is required.

Thanks for your feedback.

-- 
Anthony PERARD

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