[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Getting rid of (many) dynamic link creations in the xen build
After a short discussion on IRC yesterday I promised to send a mail how I think we could get rid of creating dynamic links especially for header files in the Xen build process. This will require some restructuring, the amount will depend on the selected way to proceed: - avoid links completely, requires more restructuring - avoid only dynamically created links, i.e. allowing some static links which are committed to git The difference between both variants is affecting the public headers in xen/include/public/: avoiding even static links would require to add another directory or to move those headers to another place in the tree (either use xen/include/public/xen/, or some other path */xen), leading to the need to change all #include statements in the hypervisor using <public/...> today. The need for the path to have "xen/" is due to the Xen library headers (which are installed on user's machines) are including the public hypervisor headers via "#include <xen/...>" and we can't change that scheme. A static link can avoid this problem via a different path, but without any link we can't do that. Apart from that decision, lets look which links are created today for accessing the header files (I'll assume my series putting the library headers to tools/include will be taken, so those links being created in staging today are not mentioned) and what can be done to avoid them: - xen/include/asm -> xen/include/asm-<arch>: Move all headers from xen/include/asm-<arch> to xen/arch/<arch>/include/asm and add that path via "-I" flag to CFLAGS. This has the other nice advantages that most architecture specific files are now in xen/arch (apart from the public headers) and that we can even add generic fallback headers in xen/include/asm in case an arch doesn't need a specific header file. - xen/arch/<arch>/efi/*.[ch] -> xen/common/efi/*.[ch]: Use vpath for the *.c files and the "-I" flag for adding common/efi to the include path in the xen/arch/<arch>/efi/Makefile. - tools/include/xen/asm -> xen/include/asm-<arch>: Add "-Ixen/arch/<arch>/include" to the CFLAGS. It might be a nice idea to move the headers needed by the tools to xen/arch/include/tools/asm and use "-Ixen/arch/<arch>/include/tools" instead, but this would require either the same path added to the hypervisor's CFLAGS or a modification of the related #include statements. - tools/include/xen/foreign -> tools/include/xen-foreign: Get rid of tools/include/xen-foreign and generate the headers directly in xen/include/public/foreign instead. - tools/include/xen/sys -> tools/include/xen-sys/<OS>: Move the headers from tools/include/xen-sys/<OS> to tools/include/<OS>/xen/sys/ and add the appropriate path to CFLAGS. - tools/include/xen/lib/<arch>/* -> xen/include/xen/lib/<arch>/*: Move xen/include/xen/lib/<arch> to xen/include/tools/lib/<arch> and add "-Ixen/include/tools" to the CFLAGS of tools. - tools/include/xen/libelf/* -> xen/include/xen/*: Move the affected headers from xen/include/xen to xen/include/tools/libelf and reuse the above set CFLAGS. - tools/include/xen/xsm -> xen/include/public/xsm: No longer needed (see next item in the list). - tools/include/xen/* -> xen/include/public/*: See above discussion of the two possible variants. Either add a static link in git from tools/include/xen -> xen/include/public (now possible with all links below tools/include/xen gone), or add "-Ixen/include/public" to the tools' CFLAGS. - stubdom/include/* -> tools/include/*: Set "-Itools/include -Itools/include/MiniOS" for the CFLAGS. I hope I have covered everything. Thoughts (especially about the two possible variants)? Juergen
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |