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

Re: [XEN PATCH] xen: allow XSM_FLASK_POLICY only if checkpolicy binary is available


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Anthony PERARD <anthony.perard@xxxxxxxxxx>
  • Date: Fri, 16 Jul 2021 17:23:33 +0100
  • Authentication-results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: Jan Beulich <jbeulich@xxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, "Stefano Stabellini" <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 16 Jul 2021 16:23:44 +0000
  • Ironport-hdrordr: A9a23:z1oXmK0j/hYXLB0JHdLMSQqjBIokLtp133Aq2lEZdPRUGvb4qy mLpoV96faSskd2ZJhAo6HlBEDuex/hHPJOjrX5eI3SJTUO21HYSb2Kj7GSoAEIcheWnoU2uJ uIMZIOauEYZWIK9foSizPZLz9P+re6zJw=
  • Ironport-sdr: zq2UcFMgoXyXVKIlxFtAFNbALSi2BQIXdlWQ+t6wicQdwSIJMEuigrGPi8fpXC5ZDfWkLaKPeL mjt2RGR267CXG7F4zE8kZHrIBIYnMmNGq0bbptxn69UZSMwsOom2ixpO9eJQbN0+d+n/6rSOVa elyM6HOVWJWqLyrrt+5qMFy/rH04YHk5WZjKxmQI68IyW4EOMLn4zmMMLlK0tLerJJrUKoL671 EwebFX6++BTNdgg4OV8GshR7cYZ2WCL5Qga/efsU4O7O43nE+4wLY5WSMdan00egPp+a19Tg4z k1I=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri, Jul 16, 2021 at 02:15:28PM +0100, Andrew Cooper wrote:
> On 15/07/2021 07:25, Jan Beulich wrote:
> > On 14.07.2021 18:17, Anthony PERARD wrote:
> >> --- a/xen/common/Kconfig
> >> +++ b/xen/common/Kconfig
> >> @@ -25,6 +25,9 @@ config GRANT_TABLE
> >>  config HAS_ALTERNATIVE
> >>    bool
> >>  
> >> +config HAS_CHECKPOLICY
> >> +  def_bool $(success,$(CHECKPOLICY) -h 2>&1 | grep -q xen)
> >> +
> > This is no different from other aspects of "Kconfig vs tool chain
> > capabilities" sent out last August to start a discussion about
> > whether we really want such. Besides Jürgen no-one cared to reply
> > iirc, which to me means no-one really cares one way or the other.
> 
> You know full well that upgrading Kconfig was specifically to be able to
> use this functionality, and you know full well that I firmly support

To be honest, I've upgraded Kconfig mostly because I needed to start
somewhere with upgrading our build system to look more like Kbuild. I
may have adding `CC --version` and some other CONFIG_* running shells,
but I don't think anymore that is a necessary things to do, it just look
cleaner.

> using this mechanism, because we've had both of these arguments several
> times before.

I'd like to read about your (or someone else's) arguments in favor of
doing more in Kconfig only, do you have links (or maybe subject,
keyword) to look at?

I think I understand Jan's arguments.

Cheers,

-- 
Anthony PERARD



 


Rackspace

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