Re: [PATCH 02/12] x86/boot: eliminate module_map

["Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>]

On 11/6/24 09:55, Andrew Cooper wrote:
> On 06/11/2024 2:50 pm, Daniel P. Smith wrote:
> > On 11/6/24 09:34, Andrew Cooper wrote:
> > > However, despite looking at this many times, I've only just realised...
> > > This semantically changes things in a direction that we won't want.
> > >
> > > Today, BOOTMOD_RAMDISK only happens a side effect of being "first
> > > BOOTMOD_UNKNOWN standing at the end".
> > >
> > > But the EFI boot code ought to set bi->type=RAMDISK explicitly from the
> > > ramdisk= argument (it can probably set type=MICROCODE too), and future
> > > plans with a large HL config probably will be similar.
> > >
> > > Anything which sets type=, and type=RAMDISK in particular, prior to
> > > early_microcode_load() excludes it from the search.  This is definitely
> > > not what we want.
> > >
> > >
> > > It's a latent bug for now, but I'd suggest keeping the plain for
> > > loop, with
> > >
> > >               /* Search anything unclaimed or likely to be a CPIO
> > > archive. */
> > >               if ( bm->type != BOOTMOD_UNKNOWN &&
> > >                    bm->type != BOOTMOD_RAMDISK )
> > >                   continue;
> > >
> > > as the selection criteria.  Probably also want to start from idx=0 to
> > > remove assumptions about the dom0 kernel.
> > >
> > > Thoughts?
> > Yah, as much as it would be nice to use the helper, this is the
> > exception where there is a complex match condition to be handled. This
> > will be switched over to an explicit for loop.
> This is simple enough, and I'm happy to fix this all up on commit.  Save
> it going around the loop yet again.
No objection on my part, as I was just going to make the changes as you 
suggested.
v/r,
dps