From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: The most recent attempt to build 2.6.29-rc8 Date: Wed, 25 Mar 2009 10:45:43 -0700 Message-ID: <49CA6DC7.6000307@goop.org> References: <276529.49208.qm@web56105.mail.re3.yahoo.com> <49C9E9AC.8070907@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: M A Young Cc: Boris Derzhavets , Xen-devel List-Id: xen-devel@lists.xenproject.org M A Young wrote: > On Wed, 25 Mar 2009, M A Young wrote: > >> On Wed, 25 Mar 2009, Jeremy Fitzhardinge wrote: >> >>> M A Young wrote: >>>> On Sun, 22 Mar 2009, Boris Derzhavets wrote: >>>> >>>>> Yes, i've noticed also that after build completed >>>>> >>>>> CONFIG_XEN_XENBUS_FRONTEND >>>>> gets reset to "m" >>>> >>>> I think the attached patch fixes the XEN_XENBUS_FRONTEND >>>> configuration dependencies. >>> >>> (This patch was full of ^M's) >> >> That's strange because it wasn't when I sent it. I wonder if it got >> mangled in-transit. >> >>> Unfortunately this didn't help me; it still ended up making this >>> 'm', which doesn't work. The simple fix is, I think, to make this a >>> "bool", so it gets built in. Its not really big enough to bother with. >> >> I have been using XEN_XENBUS_FRONTEND=m on some of my kernels so it >> didn't cause me a problem, though of course if any of the dependent >> modules were "y" then that would indeed be incorrect. I did have an >> alternate way of doing it that I could try. > > I should probably have said that the alternate idea was to remove the > selects, then make XEN_XENBUS_FRONTEND default y and depends on > XEN_FBDEV_FRONTEND || XEN_NETDEV_FRONTEND || XEN_BLKDEV_FRONTEND || > XEN_KBDDEV_FRONTEND Doesn't scale very well as we add more frontends though. I don't see a huge benefit in making it separately compilable anyway; it's pretty small, and I can't think of much plausible use for a Xen kernel without frontends. (On the other hand, making all of xenbus a single module might be useful, so that a non-Xen boot doesn't have to carry it.) J