From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: Andrew Jones <drjones@redhat.com>,
xen-devel@lists.xensource.com,
virtualization@lists.linux-foundation.org,
Jeremy Fitzhardinge <jeremy@goop.org>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
Date: Wed, 11 Jan 2012 12:27:00 -0500 [thread overview]
Message-ID: <20120111172700.GA4449@phenom.dumpdata.com> (raw)
In-Reply-To: <20120111161911.GB18203@andromeda.dapyr.net>
On Wed, Jan 11, 2012 at 12:19:11PM -0400, Konrad Rzeszutek Wilk wrote:
> > > If the root complaint is that "customers think that anything set in
> > > .config is a supported feature", then the solutions are to support
> > > all
> > > the features in .config, re-educate the customers that they're wrong,
> > > or
> > > maintain a local patch to do this stuff.
> >
> > If only re-educating people was free, like preempting questions is.
> > Local patches are of course always an option, and perhaps in this
> > case it's the best one. However, I think we already made a case for
> > better xen configurability for the driver domains, so I'm not 100%
>
> Could you repost those backend patches please? At this point I am not
> sure which one we have discarded?
hm, I was thinking in terms of the XenBus ones. We had somewhere in this
converstion something about seperating the backend's from depending on
CONFIG_XEN_DOM0 as they can be run in any domain nowadays.
>
> > convinced my initial patch (making dom0 configurable) isn't worthy
> > of upstream. Also, I didn't see any comments on my v2[*] of that
> > patch, which I believe satisfies the menu complexity issue and
> > brings in more configurability. That said, I'm about to reply to
> > that patch myself, since there's an issue with it.
> >
> > Drew
> >
> > [*] http://article.gmane.org/gmane.linux.kernel.virtualization/14635
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2012-01-11 17:27 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-06 16:39 [PATCH] xen: remove CONFIG_XEN_DOM0 compile option Andrew Jones
2012-01-06 16:59 ` Stefano Stabellini
2012-01-09 10:37 ` [Xen-devel] " Andrew Jones
2012-01-09 11:39 ` Stefano Stabellini
2012-01-09 14:56 ` Konrad Rzeszutek Wilk
2012-01-09 16:12 ` Stefano Stabellini
2012-01-09 17:04 ` Konrad Rzeszutek Wilk
2012-01-09 17:38 ` Andrew Jones
2012-01-09 18:44 ` Stefano Stabellini
2012-01-10 0:57 ` Jeremy Fitzhardinge
2012-01-10 0:57 ` Jeremy Fitzhardinge
2012-01-11 15:37 ` [Xen-devel] " Andrew Jones
2012-01-11 16:19 ` Konrad Rzeszutek Wilk
2012-01-11 16:36 ` [PATCH 1/4] xen kconfig: keep XEN_XENBUS_FRONTEND builtin Andrew Jones
2012-01-11 16:36 ` [PATCH 2/4 v2] xen kconfig: relax INPUT_XEN_KBDDEV_FRONTEND deps Andrew Jones
2012-01-11 17:30 ` Konrad Rzeszutek Wilk
2012-01-12 10:59 ` Andrew Jones
2012-01-11 16:36 ` [PATCH 3/4 v2] xen kconfig: add dom0 support help text Andrew Jones
2012-01-11 16:36 ` [PATCH 4/4] xen kconfig: describe xen tmem in the config menu Andrew Jones
2012-01-11 17:35 ` Konrad Rzeszutek Wilk
2012-01-12 10:54 ` Andrew Jones
2012-01-11 17:28 ` [PATCH 1/4] xen kconfig: keep XEN_XENBUS_FRONTEND builtin Konrad Rzeszutek Wilk
2012-01-12 10:49 ` [Xen-devel] " Andrew Jones
2012-01-12 14:37 ` Konrad Rzeszutek Wilk
2012-01-12 15:42 ` Bastian Blank
2012-01-12 15:42 ` Bastian Blank
2012-01-12 17:46 ` [Xen-devel] " Andrew Jones
2012-01-11 17:28 ` Konrad Rzeszutek Wilk
2012-01-11 17:27 ` [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option Konrad Rzeszutek Wilk
2012-01-11 17:27 ` Konrad Rzeszutek Wilk [this message]
2012-01-12 10:53 ` Andrew Jones
2012-01-09 18:12 ` Stefano Stabellini
2012-01-09 17:26 ` Andrew Jones
2012-01-06 17:16 ` Ian Campbell
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=20120111172700.GA4449@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=drjones@redhat.com \
--cc=jeremy@goop.org \
--cc=konrad@darnok.org \
--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 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.