[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [edk2] [PATCH v3 02/19] OvmfPkg: Add public headers from Xen Project.



On Sun, Oct 19, 2014 at 04:47:32PM -0700, Jordan Justen wrote:
> On 2014-10-17 10:03:45, Anthony PERARD wrote:
> > This patch imports publics headers in order to use features from Xen
> > like XenStore, PV Block... There is only the necessary header files and
> > there are only a few modifications in order to facilitate future merge of
> > more recent header (that would be necessary to access new features).
> > 
> > There is little modification compared to the original files:
> > - Removed most of the unused part of the headers
> > - Use of ZeroMem() instead of memset()
> > - using #pragma pack(4) for IA32 compilation.
> 
> Usually EDK II uses pack(1) when concerned about structure layout. I'm
> not saying you need to change this, but it does stand out.
> 
> > - Replace types to be more UEFI compliant using a script.
> > 
> > OVMF, when built for IA32 arch, uses the gcc switch -malign-double. This
> > change the alignment of fields in some struct compare to what is
> > espected by Xen and any backends. To fix the alignment, the #pragma pack(4)
> > directive is used around the struct that need it.
> > 
> > Command to run to change types:
> > find OvmfPkg/Include/IndustryStandard/Xen -type f -name '*.h' -exec sed
> >   --regexp-extended --file=fix_type_in_xen_includes.sed --in-place {} \;
> 
> Did you intend to include fix_type_in_xen_includes.sed?

No, I did not. I though that having the content of the script in the
commit message would be enough. I guest that I could add a README in to
OvmfPkg/Include/IndustryStandard/Xen, so it will be easier for the next
person to find the information.

> Maybe you could mention the source (url, version) for the files? Was
> it a direct copy into OvmfPkg/Include/IndustryStandard/Xen before
> using the script?
> 
> How easy do you think someone could 'update' the files from Xen based
> on the information you provided here?

I guest it would not be to hard, I've put in this commit message
everything I've done to import the headers.

> > This line is commented instead of been change as I'm not sure why it
> > does not compile (when s/char/CHAR8/), and it does not seems necessary
> > so far.
> >   /* __DEFINE_XEN_GUEST_HANDLE(uchar, unsigned char); */
> 
> Could 'unsigned char' => 'UINT8' help?

I'll give it a try.

> -Jordan
> 
> >   in OvmfPkg/Include/IndustryStandard/Xen/arch-x86/xen.h
> > 
> > Avoid changing the 'long' that is not a type (with the first line).
> > $ cat fix_type_in_xen_includes.sed
> > /as long as/b
> > 
> > s/([^a-zA-Z0-9_]|^)uint8_t([^a-zA-Z0-9_]|$)/\1UINT8\2/g
> > s/([^a-zA-Z0-9_]|^)uint16_t([^a-zA-Z0-9_]|$)/\1UINT16\2/g
> > s/([^a-zA-Z0-9_]|^)uint32_t([^a-zA-Z0-9_]|$)/\1UINT32\2/g
> > s/([^a-zA-Z0-9_]|^)uint64_t([^a-zA-Z0-9_]|$)/\1UINT64\2/g
> > 
> > s/([^a-zA-Z0-9_]|^)int8_t([^a-zA-Z0-9_]|$)/\1INT8\2/g
> > s/([^a-zA-Z0-9_]|^)int16_t([^a-zA-Z0-9_]|$)/\1INT16\2/g
> > s/([^a-zA-Z0-9_]|^)int32_t([^a-zA-Z0-9_]|$)/\1INT32\2/g
> > s/([^a-zA-Z0-9_]|^)int64_t([^a-zA-Z0-9_]|$)/\1INT64\2/g
> > 
> > s/([^a-zA-Z0-9_]|^)void([^a-zA-Z0-9_]|$)/\1VOID\2/g
> > s/([^a-zA-Z0-9_]|^)unsigned int([^a-zA-Z0-9_]|$)/\1UINT32\2/g
> > s/([^a-zA-Z0-9_]|^)int([^a-zA-Z0-9_]|$)/\1INT32\2/g
> > s/([^a-zA-Z0-9_]|^)char([^a-zA-Z0-9_]|$)/\1CHAR8\2/g
> > s/([^a-zA-Z0-9_]|^)unsigned long([^a-zA-Z0-9_]|$)/\1UINTN\2/g
> > s/([^a-zA-Z0-9_]|^)long([^a-zA-Z0-9_]|$)/\1INTN\2/g

-- 
Anthony PERARD

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.