[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Getting rid of (many) dynamic link creations in the xen build
On 15.10.20 12:09, Jan Beulich wrote:
On 15.10.2020 09:58, Jürgen Groß wrote:
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
While I like the latter better, I'd like to point out that not all
file systems support symlinks, and hence the repo then couldn't be
stored on (or the tarball expanded onto) such a file system. Note
that this may be just for viewing purposes - I do this typically at
home -, i.e. there's no resulting limitation from the build process
needing symlinks. Similarly, once we fully support out of tree
builds, there wouldn't be any restriction from this as long as just
the build tree is placed on a capable file system.
As a result I'd like to propose variant 2´: Reduce the number of
dynamically created symlinks to a minimum. This said, I have to
admit that I haven't really understood yet why symlinks are bad.
They exist for exactly such purposes, I would think.
Not the symlinks as such, but the dynamically created ones seem to be
a problem, as we stumble upon those again and again.
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.
Iirc Andrew suggested years ago that we follow Linux in this regard
(and XTF already does). My only concern here is the churn this will
cause for backports.
Changing a directory name in a patch isn't that hard, IMO.
- 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.
Fine with me.
- 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.
Separating headers intended for tools consumption is okay with me,
but I dislike the tools/ infix in the path you suggest. Since there
can't possibly be any shared prototypes, how about defs/ or some
such not specifically naming either of the consuming components
(and thus visually excluding the other)?
I have absolutely no preferences for the naming. defs is fine IMO.
Of course, the further asm/ underneath is kind of ugly because of
being largely unnecessary. Perhaps we could have just
xen/arch/include/defs/ and use #include <defs/xyz.h>?
Yes, that should work, too.
- 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.
Except that conceptually building in tools/ would better not alter
the xen/ subtree in any way.
I meant to generate the headers from the hypervisor build 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.
Not very nice imo because of the otherwise pointless intermediate
directories, but if we truly need to minimize symlink usage, then
so be it.
- 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.
Why not -Ixen/include/xen without any movement? Perhaps because
This would open up most of the hypervisor private headers to be
easily includable by tools.
-Ixen/include/tools wouldn't work either, due to code using
#include <xen/lib/<arch>/xyz.h>
? I.e. you really mean Move xen/include/xen/lib/<arch> to
xen/include/tools/xen/lib/<arch>? Not very nice. I have to admit
I can't see why the header in xen/include/xen/lib/<arch>/ don't
use
#include "xyz.h"
But then this would leave the problem with xen/lib/<arch>/*.c
using similar #include-s. Would dropping xen/ from the paths
perhaps help, moving xen/include/xen/lib/* to xen/include/lib/*?
Istr suggesting this when the lib/ subtrees were introduced ...
This would at least eliminate one directory level.
- 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.
Why not xen/include/libelf/ or xen/include/lib/elf/?
libelf-private.h has distinct #include-s for Xen and the tools
anyway. All that's needed is that these headers don't sit in a
directory where headers also live which are not supposed to be
visible.
That is correct.
Juergen
|
