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

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

  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • Date: Mon, 30 Aug 2021 09:41:53 -0400
  • Arc-authentication-results: i=1; mx.zohomail.com; dkim=pass header.i=apertussolutions.com; spf=pass smtp.mailfrom=dpsmith@xxxxxxxxxxxxxxxxxxxx; dmarc=pass header.from=<dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1630330918; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=8mUYezkGPNWlbfPrt0JI7s8sUghWScRmlRM8XYAZqVA=; b=AsIYBqmaW2RpYhD+3076EyUDWmh7d4FzO8WdCHOt3tH3/6it/uYC5Osf+25lG9siRfEQ2avjmEtJANcEZ2OVLhgiUeoAEBDAFoPrsZ1A49mXiCu8aEetlMfE6yW8nn+Rn92WlmmfqP7eRZaZzs915pSSGPkcM3me6cxch0UyR0g=
  • Arc-seal: i=1; a=rsa-sha256; t=1630330918; cv=none; d=zohomail.com; s=zohoarc; b=SPaG1S/ViroJLZyPe5xn7fnBsbH9HfSxg6LzeBicxlR6H85dQdJv5ik/4Xw36IGJ1XzlDByKEdWdbiLvfcO4iwyPXFhYkumuo9N0+iqRAY/5O1JpYXDyusKUKEqdFHbTm6llox8SNLkWIbRw/A6pJn9xnzfsaZHdme7+XPTuyZY=
  • Cc: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 30 Aug 2021 13:42:06 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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

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

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.




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