[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH v7 49/51] build: adding out-of-tree support to the xen build


  • To: Anthony PERARD <anthony.perard@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 18 Oct 2021 11:02:20 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OGfZqQzLIgGlCIYuRToZYjeRdyBXa7Bk1f5CBu2G0o0=; b=CEC2cHe71yDqpEF0F1ChNKLTVma4kvHNj/mSaGtedpMwMVFSMlh4Tpwa39Zsb2ZBGDI8INefCVmtBuqP1yrZhubTvsAvREVMv0I59C/o6D6YmCrLEXQSKDJtJY/rLHeiqkzOGO6Dc6wLwmnIX3rU8rVuI+24BUkeB0q7WHQxM36Rg6+4Zks/yvGRrY6ZUlkZWkZh+f6tbEf/BpN2HSVOBt3q91IXmaNwQS0ghmKklLEGINwq4w4W2TdZH7FX2d5Wg/x3r26UIWmgv+KFJHZ1NBGMBQyUIHnuhgsND8P0I4TSvyc8ONXTD1UVdPOu+PKmzA6pEYm8ynidJTtDGO3ojg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hcvAF6HOFDuMUShQDRYclZ/Cx/lh4kH50qU31zBd1KToYH0IbpIrTi1wWX5A83IuPYC/QUQ6wNhrDyBe8MsQ8Gsx+n0VbYw1RSYL7hvUCW4z3TOnriRFPPzs0RbGLaPalS43/AIF4qsodL7lVHqUs0iIavLK542dP0xEnt0HuibZmjX8C8nLnOzMU6tkgM6MRR8Vh2g3ZP3MvROzb/7Ub4Kjkaecfp6QqjoRE//WqywGs9DYFqXJMfAwgSZkVXiiCnWTaudsLrl20sq7kOKWFgaluivhtJVAzeonTTVYQQkol1b86VafieBfKGMxUMVvmMrNg4mz56cajxL/HpEnkQ==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>, "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 18 Oct 2021 09:02:36 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 15.10.2021 18:58, Anthony PERARD wrote:
> On Thu, Oct 14, 2021 at 12:14:29PM +0200, Jan Beulich wrote:
>> On 24.08.2021 12:50, Anthony PERARD wrote:
>>> --- a/xen/Rules.mk
>>> +++ b/xen/Rules.mk
>>> @@ -38,7 +38,7 @@ SPECIAL_DATA_SECTIONS := rodata $(foreach a,1 2 4 8 16, \
>>>                           $(foreach r,rel rel.ro,data.$(r).local)
>>>  
>>>  # The filename build.mk has precedence over Makefile
>>> -mk-dir := $(src)
>>> +mk-dir := $(srctree)/$(src)
>>>  include $(if $(wildcard 
>>> $(mk-dir)/build.mk),$(mk-dir)/build.mk,$(mk-dir)/Makefile)
>>
>> Perhaps already when it was changed to $(src) the name has become
>> slightly misleading, at least imo: I would rather expect a variable
>> with this name to refer to the build dir/tree. Maybe "srcdir" or
>> even shorted "sd" right from the start? (Reaching here I can finally
>> see why having a shorthand is helpful.)
> 
> I have to think about that. I've made some further progress in order to
> be able to build the Xen pvhshim without a link farm and notice that
> nearly every source file needs to use "$(srctree)/$(src)"

Oh, now I'm curious as to the why here. I thought use of $(srctree)
ought to be the exception.

> and I'm not
> sure "$(src)" could be use alone. So having a single variable which have
> both would be useful.
> 
> "srcdir" might be to close to "srctree" and one might mistake it for the
> other, so "sd" might be better.

While I did suggest "sd" as an option, already when writing this I
wasn't convinced this would be descriptive enough. Personally I think
"dir" and "tree" are sufficiently different names. I would suggest
"srcroot" for what is now "srctree", but that would have the
disadvantage of getting us out of sync with Linux.

>>> --- a/xen/xsm/flask/ss/Makefile
>>> +++ b/xen/xsm/flask/ss/Makefile
>>> @@ -9,3 +9,6 @@ obj-y += conditional.o
>>>  obj-y += mls.o
>>>  
>>>  CFLAGS-y += -I$(srctree)/xsm/flask/include
>>> +ifdef building_out_of_srctree
>>> +    CFLAGS-y += -I$(objtree)/xsm/flask/include
>>
>> There's no header in $(srctree)/xsm/flask/include in this case, so if you
>> use "ifdef" here, shouldn't that other part move into an "else"?
> 
> Actually, there are headers in the source, like "security.h", and `git
> ls-files xen/xsm/flask/include` shows plenty other headers.

Hmm, I'm not sure now how I came to make that comment. I must have
mentally discarded the trailing "/include", looking at
xen/xsm/flask/Makefile generating a couple of headers, and then
blindly assumed these headers would land in xen/xsm/flask/. I'm
sorry for the noise.

Jan




 


Rackspace

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