Re: [PATCH v2 37/39] xen/rirscv: add minimal amount of stubs to build full Xen

[Oleksii <oleksii.kurochko@xxxxxxxxx>]

On Thu, 2023-12-21 at 09:02 +0100, Jan Beulich wrote:
> On 20.12.2023 13:55, Oleksii wrote:
> > On Mon, 2023-12-18 at 18:00 +0100, Jan Beulich wrote:
> > > On 24.11.2023 11:30, Oleksii Kurochko wrote:
> > > > --- /dev/null
> > > > +++ b/xen/arch/riscv/stubs.c
> > > > @@ -0,0 +1,426 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0-only */
> > > > +#include <xen/cpumask.h>
> > > > +#include <xen/domain.h>
> > > > +#include <xen/irq.h>
> > > > +#include <xen/nodemask.h>
> > > > +#include <xen/time.h>
> > > > +#include <public/domctl.h>
> > > > +#include <public/vm_event.h>
> > > 
> > > I think I can see why you need the former of these last two, but
> > > do
> > > you
> > > really need the latter?
> > It is needed for vm_event_request_t and vm_event_response_t, but if
> > use
> > a forward declaration that it won't be needed:
> > 
> > typedef struct vm_event_st vm_event_request_t;
> > typedef struct vm_event_st vm_event_response_t;
> 
> Iirc Misra wouldn't like the duplicating of typedef-s used elsewhere.
> But
> as long as that's not going to stay (and I expect stubs.c to go away
> before Misra becomes of concern for RISC-V), that's going to be okay,
> I
> think. Yet then avoiding the typedef-s and using struct vm_event_st
> directly in the functions would be as good, and overall less code.
Hmm, it makes sense to use sturct vm_event_st direcly in this case.
Thanks for suggestion.

~ Oleksii