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

Re: [PATCH v3 5/7] xsm: decouple xsm header inclusion selection

  • To: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 30 Aug 2021 15:46:43 +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-SenderADCheck; bh=8XsJq5znX1alfF1QVv2aA5Et7/PZa2fUuK3jKBKwtJM=; b=SpzAIxSLIM9Wj1GqIDwMHTgjPww6F6DLEph1NfPYhPPHuXS/XI0V7/M0zCvXpD2vMwcwqe6s2blyyO8xRSppoep/MZBvnsu1H3r3X527W/4YCaXRM42RFEmCeCU52ECQxVAeex5b3KiRXx/+dxbazAsE47boN1GQiqKJ8OwnlS/rbmTHPV841KSWgWBS589DvLY3c7rTkcIY29NnCxaGgy/CKuy1TdmDuTwTZYwZJOq3KLKiThp0X3zb85MjewyN8PWzzNu5yi2yc0FC1agTBRXDWXnszrxf3Sn2Mi8WF76Tw9GMCLMOsks0KsMzMygmaDLQiPacbTqYoc/KTJMRwg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PkX4fISPPj1/RwsuEAjIH3UcYzII40JBz65HjuEzL436RrSlbqrnTDMCFc+4WrRtkYjFrLXNOvERWALWxtFRKcuQcqQc635zHT40fPDCCAkWq+4jQvl/l8KEAXPrmM1SdV/hSnlZyuXWcoGTPz5KYh1E8J9ONjizAWCsTojuVUoxCqKCjFrINMKeJLxv3KaipW2uE8FEWqvPZKBs6z456e02TqkX9x6cxcUvPsmd22CVPoBMNDalBuCD4o5tZoftTTAn8bGYDDIxuggoCRWIkIfkBEUhUKyf6zshc2ThbOikf0w4w5vLJmAMDu80Qfm0zp4XxV8VpBMnniYwfWjhmg==
  • 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: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 30 Aug 2021 13:46:52 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 30.08.2021 15:41, Daniel P. Smith wrote:
> On 8/30/21 9:24 AM, Jan Beulich wrote:
>> On 27.08.2021 16:06, Daniel P. Smith wrote:
>>> On 8/26/21 4:13 AM, Jan Beulich wrote:
>>>> On 05.08.2021 16:06, Daniel P. Smith wrote:
>>>>> --- /dev/null
>>>>> +++ b/xen/include/xsm/xsm-core.h
>>>>> @@ -0,0 +1,273 @@
>>>>> +/*
>>>>> + *  This file contains the XSM hook definitions for Xen.
>>>>> + *
>>>>> + *  This work is based on the LSM implementation in Linux
>>>>> + *
>>>>> + *  Author:  George Coker, <gscoker@xxxxxxxxxxxxxx>
>>>>> + *
>>>>> + *  Contributors: Michael LeMay, <mdlemay@xxxxxxxxxxxxxx>
>>>>> + *
>>>>> + *  This program is free software; you can redistribute it and/or modify
>>>>> + *  it under the terms of the GNU General Public License version 2,
>>>>> + *  as published by the Free Software Foundation.
>>>>> + */
>>>>> +
>>>>> +#ifndef __XSM_CORE_H__
>>>>> +#define __XSM_CORE_H__
>>>>> +
>>>>> +#include <xen/sched.h>
>>>>> +#include <xen/multiboot.h>
>>>> I was going to ask to invert the order (as we try to arrange #include-s
>>>> alphabetically), but it looks like multiboot.h isn't fit for this.
>>> So my understanding is to leave this as is.
>> Yes, unfortunately.
>>>>> +typedef void xsm_op_t;
>>>>> +DEFINE_XEN_GUEST_HANDLE(xsm_op_t);
>>>> Just FTR - I consider this dubious. If void is meant, I don't see why
>>>> a void handle can't be used.
>>> Unless I am misunderstanding what you are calling for, I am afraid this
>>> will trickle further that what intended to be addressed in this patch
>>> set. If disagree and would like to provide me a suggest that stays
>>> bounded, I would gladly incorporate.
>> All I'm asking is to remove this pointless typedef and handle definition,
>> seeing that you're doing a major rework anyway. I'm afraid I don't see
>> how this would collide with the purpose of the overall series (albeit I
>> may also have misunderstood your reply, as the 2nd half of the first
>> sentence makes me struggle some with trying to parse it).
> If I drop the typedef and start changing everywhere xsm_op_t is
> referenced to void, this now adds hypercall.h to the files I am now
> touching.
> In the end it is not about whether the change is big or small, but that
> more and more unrelated small changes/clean ups keep getting requested.
> There has to be a cut-off point to limit the scope of changes down to
> the purpose of the patch set, which is to unravel and simplify the XSM
> hooks. And this is being done so, so that the the XSM-Roles work can be
> introduced to bring a more solid definition to the the default access
> control system, which itself is needed to bring in hyperlaunch.

Well, yes, you effectively suffer from XSM not having been actively
maintained for a number of years. As said in the original reply, I'd
prefer my ack to cover all the suggested changes, but I didn't mean
to insist. If this particular one goes too far for your taste, so be




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