From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: [PATCH] xen frontend driver module autoloading Date: Thu, 19 Jul 2007 13:10:08 +0200 Message-ID: <469F4690.7020602@redhat.com> References: <469CC13C.70903@redhat.com> <469E702E.5070903@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <469E702E.5070903@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: Xen Development Mailing List List-Id: xen-devel@lists.xenproject.org Jeremy Fitzhardinge wrote: > Gerd Hoffmann wrote: >> This patch (against 3.1-final) implements module autoloading for the xen >> frontend drivers by adding a uevent function for the frontend xenbus and >> some module aliases to the individual drivers. >> > > Now that Xen is upstream, Wow, finally, congratulations. > could you generate the corresponding patches > against mainline? 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? 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, ...)? cheers, Gerd