xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Jürgen Groß" <jgross@suse.com>
To: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	George Dunlap <George.Dunlap@citrix.com>
Subject: Getting rid of (many) dynamic link creations in the xen build
Date: Thu, 15 Oct 2020 09:58:05 +0200	[thread overview]
Message-ID: <85f1eea2-0c8b-de06-b9d8-69f9a7e34ea8@suse.com> (raw)

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


             reply	other threads:[~2020-10-15  7:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-15  7:58 Jürgen Groß [this message]
2020-10-15 10:09 ` Getting rid of (many) dynamic link creations in the xen build Jan Beulich
2020-10-15 10:41   ` Jürgen Groß
2020-10-15 20:52     ` Andrew Cooper
2020-10-16  6:52       ` Jan Beulich
2020-10-16  6:58     ` Jan Beulich
2020-10-16  7:25       ` Jürgen Groß
2020-10-16  8:11         ` Jan Beulich
2020-10-15 10:49   ` Jürgen Groß
2020-10-16  6:59     ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=85f1eea2-0c8b-de06-b9d8-69f9a7e34ea8@suse.com \
    --to=jgross@suse.com \
    --cc=George.Dunlap@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).