From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [PATCH] xen frontend driver module autoloading Date: Thu, 19 Jul 2007 07:39:47 -0700 Message-ID: <469F77B3.2060802@goop.org> References: <469CC13C.70903@redhat.com> <469E702E.5070903@goop.org> <469F4690.7020602@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <469F4690.7020602@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Gerd Hoffmann Cc: Xen Development Mailing List List-Id: xen-devel@lists.xenproject.org Gerd Hoffmann wrote: > Wow, finally, congratulations. > Thanks. "Now that Xen is upstream" has a certain sound, doesn't it? > Ok, somewhat broader question then: What is the plan now? Does the > request to send patches against mainline mean that active development > happens only in mainline and the parvirt_ops patch queue? What happens > with the sparse tree in 3.1? No, I don't think this is a cut-over date. The upstream stuff is obviously pretty immature compared to the xen-unstable code, so I guess we'll need to maintain both while things get moved over. In this case it was a no-brainer, since your patch is both simple and immediately applicable to the upstreamed code. > What happens with the separate > 2.6.18-based tree for unstable? Are they left as-is? Do they get > backports from mainline? How are bits handled which are not in the > paravirt_ops queue yet (dom0, x86_64, pvfb, ...)? Well, relatively simple things like devices can probably be queued up for upstream pretty quickly, since they don't need much infrastructure stuff. 64bit is waiting for us to sort out 64bit paravirt_ops, but should be reasonably straightforward after that. I've started looking at dom0; that will be... interesting. While it would be nice to upstream, we might have to make to with a reasonably maintainable out of tree patch for a while. J