From: Wei Liu <wei.liu2@citrix.com>
To: Juergen Gross <jgross@suse.com>
Cc: minios-devel@lists.xenproject.org,
xen-devel@lists.xenproject.org, Wei Liu <wei.liu2@citrix.com>,
samuel.thibault@ens-lyon.org
Subject: Re: [Minios-devel] [PATCH 1/2] mini-os: support keeping start_info structure conditionally
Date: Mon, 29 Aug 2016 13:03:18 +0100 [thread overview]
Message-ID: <20160829120318.GC8502@citrix.com> (raw)
In-Reply-To: <a31c64db-310a-017d-6419-827ece2cd0d9@suse.com>
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.
Wei.
> Juergen
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-08-29 12:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-29 11:01 [PATCH 0/2] mini-os: repair stubdom build Juergen Gross
2016-08-29 11:01 ` [PATCH 1/2] mini-os: support keeping start_info structure conditionally Juergen Gross
2016-08-29 11:09 ` Wei Liu
2016-08-29 11:17 ` [Minios-devel] " Juergen Gross
2016-08-29 11:47 ` Andrew Cooper
2016-08-29 12:28 ` Juergen Gross
2016-08-29 12:32 ` Andrew Cooper
2016-08-29 13:09 ` Juergen Gross
2016-08-29 12:03 ` Wei Liu [this message]
2016-08-29 11:01 ` [PATCH 2/2] mini-os: don't get xenbus parameters if xenbus is disabled Juergen Gross
2016-08-29 11:11 ` Wei Liu
2016-08-29 20:42 ` Samuel Thibault
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160829120318.GC8502@citrix.com \
--to=wei.liu2@citrix.com \
--cc=jgross@suse.com \
--cc=minios-devel@lists.xenproject.org \
--cc=samuel.thibault@ens-lyon.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.