|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 07/10] xen: arm: store per-boot module type instead of relying on index
On Mon, 2014-06-16 at 13:48 +0100, Julien Grall wrote:
> Hi Ian,
>
> On 06/16/2014 12:45 PM, Ian Campbell wrote:
> > This is more natural and better matches how multiboot is actually supposed
> > to
> > work.
> >
> > Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> > ---
> > xen/arch/arm/bootfdt.c | 49
> > +++++++++++++++----------------------------
> > xen/arch/arm/domain_build.c | 20 +++++++++++-------
> > xen/arch/arm/kernel.c | 15 ++++++-------
> > xen/arch/arm/setup.c | 47
> > ++++++++++++++++++++++++++++++++++++-----
> > xen/include/asm-arm/setup.h | 29 +++++++++++++++++--------
> > 5 files changed, 100 insertions(+), 60 deletions(-)
>
> It looks like you forgot to modify xsm/xsm_policy.c.
Ah, I was relying on the compiler to tell me about all uses of MOD_* but
I didn't have XSM enabled so it didn't build this file. Will fix.
> > +void add_boot_module(bootmodulekind kind, paddr_t start, paddr_t size,
> > + const char *cmdline)
> > +{
> > + struct bootmodules *mods = &bootinfo.modules;
> > + struct bootmodule *mod;
> > +
> > + if ( mods->nr_mods == MAX_MODULES )
> > + {
> > + printk("Ignoring boot module at %"PRIpaddr"-%"PRIpaddr" (too
> > many)\n",
> > + start, start + size);
> > + return;
> > + }
>
> As we don't have any way to know if the user add multiple the kernel
> and/or the initramfs, I would add a print message here to say what kind
> of boot module we are currently adding. It will help the guy to find the
> problem quickly.
OK.
> [..]
>
> > void __init discard_initial_modules(void)
> > {
> > struct bootmodules *mi = &bootinfo.modules;
> > int i;
> >
> > - for ( i = MOD_DISCARD_FIRST; i <= mi->nr_mods; i++ )
> > + for ( i = 0; i <= mi->nr_mods; i++ )
> > {
> > paddr_t s = mi->module[i].start;
> > paddr_t e = s + PAGE_ALIGN(mi->module[i].size);
> >
> > - dt_unreserved_regions(s, e, init_domheap_pages, 0);
> > + if ( mi->module[i].kind > BOOTMOD_LAST_PRESERVE )
> > + dt_unreserved_regions(s, e, init_domheap_pages, 0);
> > }
>
> [..]
>
>
> > +typedef enum {
> > + BOOTMOD_XEN,
> > + BOOTMOD_FDT,
> > + /* Everything up to here is not freed after start of day */
> > + BOOTMOD_LAST_PRESERVE = BOOTMOD_FDT,
>
> Currently we also discard the FDT, this is because the FDT is copied
> another place in the memory. With this patch the FDT module stays in memory.
>
> I think BOOTMOD_LAST_PRESERVE should be equal to BOOTMOD_XEN.
Agreed, this was an unintentional change.
> > + BOOTMOD_KERNEL,
> > + BOOTMOD_RAMDISK,
> > + BOOTMOD_XSM,
> > + BOOTMOD_UNKNOWN
> > +} bootmodulekind;
>
> I would rename to bootmodule_kind. It's easier to read and you know that
> the enum is used for a bootmodule.
OK.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |