On Thu, Jul 11, 2013 at 08:13:58PM +0200, Paul Bolle wrote:

On Thu, 2013-07-11 at 10:57 -0700, H. Peter Anvin wrote:

quoted

On 07/11/2013 03:08 AM, Paul Bolle wrote:

quoted

But the Kconfig entry for XEN_PRIVILEGED_GUEST reads: 
    # Dummy symbol since people have come to rely on the PRIVILEGED_GUEST
    # name in tools.
    config XEN_PRIVILEGED_GUEST
            def_bool XEN_DOM0

In other words: CONFIG_XEN_PRIVILEGED_GUEST should always be equal to
CONFIG_XEN_DOM0. So the two grep commands should always both evaluate to
true or both evaluate to false. One of these two commands can safely be
dropped.

Not necessarily true across kernel versions.

Correct. But it has actually been true ever since this Kconfig entry was
introduced in v2.6.37 (commit 6b0661a5e6fbfb159b78a39c0476905aa9b575fe,
"xen: introduce XEN_DOM0 as a silent option").

So people need not worry about breaking grub2 by dropping
XEN_PRIVILEGED_GUEST.

Right, but when we drop the CONFIG_XEN_DOM0 as well (and have instead a
CONFIG_XEN_HARDWARE_DOMAIN_SOMETHING_LIKE_THAT_I_FORGOT_NOW_THE_NAME),
then this will be a problem. Sander's proposal on fixing it "right" in
grub2 using whatever is the proper way (whatever that is) is the right
thing to do first.

Then we can make the Kconfig entries be more in line with the different
divisions of guest types - instead of the simplified
'dump-it-all-in-dom0'. This means more surgery in the Kconfig than the
initial patch posted here. This assuming that both Peter's and Boris's
assertion that CONFIG_* entries do not fall in the "must not break
user-space" category.