[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.2020 12:41, Jürgen Groß wrote:
> 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.

Well, the machinery to get them put in place needs to be fixed
(and adjustments / additions be done more carefully). Taking
together with what Andrew has said, option 2´ would move us in
the same direction then.

>>> 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.

It's not hard at all, no, but it still takes some of the most precious
resource we have: time.

>>> - 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.

This would make the tools/ build dependent upon xen/ having got
built first aiui, which I think we want to avoid.

>>> - 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.

Without the xen/ prefix, yes. But if someone wants to violate the
naming scheme to get at them, adding a suitable number of ../ will
also work as soon as symlinks aren't being used, or symlinks of
full directories are used instead of ones referencing individual




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