Re: Getting rid of (many) dynamic link creations in the xen build

[Jan Beulich <jbeulich@xxxxxxxx>]

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

Jan