From: Andrew Jones <drjones@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
virtualization@lists.linux-foundation.org,
Ian Campbell <Ian.Campbell@citrix.com>,
konrad wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH 3/4] xen kconfig: add dom0 support help text
Date: Fri, 06 Jan 2012 07:24:12 -0500 (EST) [thread overview]
Message-ID: <a0f8cfee-aeee-4993-a433-4166d63a34e6@zmail13.collab.prod.int.phx2.redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1201061051410.3150@kaball-desktop>
----- Original Message -----
> On Fri, 6 Jan 2012, Andrew Jones wrote:
> > > Almost all of the things which dom0 needs (e.g. PCI device
> > > management
> > > etc) is also required by a domU with passthrough enabled so the
> > > savings
> > > are really very slight.
> > >
> > > We are talking less than 1k of code AFAICT, 319 bytes for
> > > arch/x86/xen/vga.o and 573 for drivers/xen/xenfs/xenstored.o plus
> > > whatever xen_register_gsi (a couple of dozen lines of code) adds
> > > to
> > > arch/x86/pci/xen.o. grep doesn't show CONFIG_XEN_DOM0 being used
> > > anywhere else. What savings do you see in practice from disabling
> > > just
> > > this symbol?
> >
> > I completely agree that the saving are near none. The savings,
> > however,
> > aren't the only reason to drive the change. It's actually the
> > symbol
> > name itself. Unfortunately configs can be perceived as a contract
> > of
> > support, i.e. if feature xyz is enabled in the distro's config,
> > then
> > the distributor must have selected, and therefore will support,
> > said
> > feature.
> >
> > I didn't make this motivation clear in my initial post, because I
> > was
> > hoping to spare people some eye rolling.
>
> I thought that in the kernel community we make decisions based on
> technical merits rather than "contracts of support".
Sorry.
> Given that disabling the symbol saves near to nothing, the logical
> thing
> to do is removing the symbol altogether.
>
I thought of that too. If the symbol just goes away, then my
non-technical requirement will be met and the functionality will
stay. I consider that a bigger win actually. I didn't suggest it
though, since I've never done any dom0 development, nor had any
consideration for dom0 code needs of the future. With
anti-credentials like that, I'd guess it'd be tougher for me to sell
the need to remove it, than it is for me to just make it
configurable.
Drew
next prev parent reply other threads:[~2012-01-06 12:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-06 8:57 [PATCH 0/4] xen kconfig tweaks Andrew Jones
2012-01-06 8:57 ` [PATCH 1/4] xen kconfig: keep XEN_XENBUS_FRONTEND builtin Andrew Jones
2012-01-06 8:57 ` [PATCH 2/4] xen kconfig: relax INPUT_XEN_KBDDEV_FRONTEND deps Andrew Jones
2012-01-06 10:38 ` Stefano Stabellini
2012-01-06 10:42 ` Stefano Stabellini
2012-01-06 8:57 ` [PATCH 3/4] xen kconfig: add dom0 support help text Andrew Jones
2012-01-06 9:20 ` Ian Campbell
2012-01-06 9:26 ` Andrew Jones
2012-01-06 9:55 ` [Xen-devel] " Ian Campbell
2012-01-06 10:42 ` Stefano Stabellini
2012-01-06 10:45 ` Andrew Jones
2012-01-06 11:21 ` [Xen-devel] " Stefano Stabellini
2012-01-06 12:24 ` Andrew Jones [this message]
2012-01-06 12:35 ` Stefano Stabellini
2012-01-06 12:43 ` Andrew Jones
2012-01-06 15:07 ` [Xen-devel] " Konrad Rzeszutek Wilk
2012-01-06 8:57 ` [PATCH 4/4] xen kconfig: describe xen tmem in the config menu Andrew Jones
-- strict thread matches above, loose matches on Subject: below --
2012-01-06 9:43 [PATCH 0/4] xen kconfig tweaks Andrew Jones
2012-01-06 9:43 ` [PATCH 3/4] xen kconfig: add dom0 support help text Andrew Jones
2012-01-23 18:42 ` Konrad Rzeszutek Wilk
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=a0f8cfee-aeee-4993-a433-4166d63a34e6@zmail13.collab.prod.int.phx2.redhat.com \
--to=drjones@redhat.com \
--cc=Ian.Campbell@citrix.com \
--cc=jeremy@goop.org \
--cc=konrad.wilk@oracle.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=xen-devel@lists.xensource.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).