[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Minios-devel] [PATCH 1/2] mini-os: support keeping start_info structure conditionally

On Mon, Aug 29, 2016 at 01:17:56PM +0200, Juergen Gross wrote:
> On 29/08/16 13:09, Wei Liu wrote:
> > On Mon, Aug 29, 2016 at 01:01:08PM +0200, Juergen Gross wrote:
> >> grub stubdom needs the start_info structure. Keep a copy of it in
> >> pv mini-os if configured via "CONFIG_KEEP_STARTINFO". This should
> >> default to "n" in order to have it enabled only when really needed.
> >>
> > 
> > I'm not sure I understand the rationale for this.
> > 
> > Shouldn't start_info always be kept when mini-os is PV? Under what
> > condition should it not be kept?
> The application on top of Mini-OS shouldn't depend on Mini-OS being
> paravirtualized or not in the "normal" case. grub-stubdom is a
> special case, as it needs to kexec to a loaded kernel which in turn
> needs the start_info, of course.
> ioemu-stubdom OTOH should not need start_info as it could work on
> a HVMlite Mini-OS, too.
> The idea of removing start_info in my HVMlite series was driven by
> that thought: any application using start_info should break as it
> clearly wouldn't be agnostic of the mode (pv or HVMlite) of Mini-OS.
> pv-grub was an oversight here.
> I'm planning to modify ioemu-stubdom in the future to not use
> start_info and then let it run in HVMlite mode, too.

Right. I think we're on the same page regarding how apps should be like.

Would it be sufficient that pv-grub has a hard dependency on PV mini-os?
That should avoid yet another config option. And the semantics seems
rather strange.

But in the end I don't think I would argue strongly one way or the
other because the config option your introduced defaults to n.


> Juergen

Minios-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.