Xen devel - Jul 2007 - [PATCH] xen frontend driver module autoloading

Hi,

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.

please apply,

  Gerd


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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, could you generate the corresponding patches
against mainline?

Thanks,
    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel