Re: [PATCH] stubdom/grub: avoid relying on start_info definition

[Jürgen Groß <jgross@xxxxxxxx>]

On 25.06.25 16:30, Andrew Cooper wrote:
> On 25/06/2025 3:28 pm, Jürgen Groß wrote:
> > On 25.06.25 16:20, Jan Beulich wrote:
> > > On 25.06.2025 13:08, Juergen Gross wrote:
> > > > @@ -432,3 +431,10 @@ out:
> > > >        allocated = 0;
> > > >        xc_interface_close(xc_handle );
> > > >    }
> > > > +
> > > > +static void call_start_info_hook(struct xc_dom_image *dom)
> > > > +{
> > > > +#undef start_info
> > > > +    if ( dom->arch_hooks->start_info )
> > > > +        dom->arch_hooks->start_info(dom);
> > > > +}
> > > Maybe add a comment ahead of the function clarifying that it ought to
> > > remain
> > > last?
> > Good idea.
> >
> > I'll add:
> >
> > /* No references to start_info of Mini-OS after this function. */
> Given how few uses of start_info there actually are, can't you just drop
> that piece of extreme obfuscation and make this work like regular C?
Hmm, you mean by using start_info_ptr directly?

This would be possible, but it would introduce a two-way dependency between
xen.git and minios.git.

Right now the build is basically fine, as Config.mk doesn't reference the
variant of Mini-OS breaking today's grub-pv.

Applying my current patch to grub-pv will still work with the "old" Mini-OS,
which then could be updated to a commit-id containing the related Mini-OS
patch defining start_info differently.

This update strategy would not result in a situation where the build is broken,
while modifying grub-pv to use start_info_ptr directly isn't possible without
either breaking the build in between (we'd need a Mini-OS update for that to
have "EXPORT_SYMBOL(start_info_ptr);" included), or by taking my current patch
as an intermediate step and only then switch grub-pv to use start_info_ptr.

Thoughts?


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature