|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 2/4] xen/version: Drop compat/kernel.c
On 04/01/2023 4:29 pm, Jan Beulich wrote:
> On 03.01.2023 21:09, Andrew Cooper wrote:
>> kernel.c is mostly in an #ifndef COMPAT guard, because compat/kernel.c
>> reincludes kernel.c to recompile xen_version() in a compat form.
>>
>> However, the xen_version hypercall is almost guest-ABI-agnostic; only
>> XENVER_platform_parameters has a compat split. Handle this locally, and do
>> away with the reinclude entirely.
> And we henceforth mean to not introduce any interface structures here
> which would require translation (or we're willing to accept the clutter
> of handling those "locally" as well). Fine with me, just wanting to
> mention it.
Sure - I'll put a note in the commit message.
In general, we don't want guest-variant interfaces.
>
>> --- a/xen/common/compat/kernel.c
>> +++ /dev/null
>> @@ -1,53 +0,0 @@
>> -/******************************************************************************
>> - * kernel.c
>> - */
>> -
>> -EMIT_FILE;
>> -
>> -#include <xen/init.h>
>> -#include <xen/lib.h>
>> -#include <xen/errno.h>
>> -#include <xen/version.h>
>> -#include <xen/sched.h>
>> -#include <xen/guest_access.h>
>> -#include <asm/current.h>
>> -#include <compat/xen.h>
>> -#include <compat/version.h>
>> -
>> -extern xen_commandline_t saved_cmdline;
>> -
>> -#define xen_extraversion compat_extraversion
>> -#define xen_extraversion_t compat_extraversion_t
>> -
>> -#define xen_compile_info compat_compile_info
>> -#define xen_compile_info_t compat_compile_info_t
>> -
>> -CHECK_TYPE(capabilities_info);
> This and ...
>
>> -#define xen_platform_parameters compat_platform_parameters
>> -#define xen_platform_parameters_t compat_platform_parameters_t
>> -#undef HYPERVISOR_VIRT_START
>> -#define HYPERVISOR_VIRT_START HYPERVISOR_COMPAT_VIRT_START(current->domain)
>> -
>> -#define xen_changeset_info compat_changeset_info
>> -#define xen_changeset_info_t compat_changeset_info_t
>> -
>> -#define xen_feature_info compat_feature_info
>> -#define xen_feature_info_t compat_feature_info_t
>> -
>> -CHECK_TYPE(domain_handle);
> ... this go away without any replacement. Considering they're both
> char[], that's probably fine, but could do with mentioning in the
> description.
I did actually mean to ask about these two, because they're incomplete
already.
Why do we CHECK_TYPE(capabilities_info) but define identity aliases for
compat_extraversion (amongst others) ?
Is there even a point for having a compat alias of a char array?
I'm tempted to just drop them. I don't think the check does anything
useful for us.
>> @@ -520,12 +518,27 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void)
>> arg)
>>
>> case XENVER_platform_parameters:
>> {
>> - xen_platform_parameters_t params = {
>> - .virt_start = HYPERVISOR_VIRT_START
>> - };
> With this gone the oddly (but intentionally) placed braces can then
> also go away.
In light of how patch 3 ended up, I was considering pulling curr out
into a variable.
> Preferably with these minor adjustments
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
Thanks,
~Andrew
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |