[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |