xen frontend driver module autoloading
PATCH 1/1 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
--- linux-2.6-xen-sparse/drivers/xen/blkfront/blkfront.c | 2 - linux-2.6-xen-sparse/drivers/xen/fbfront/xenfb.c | 1 linux-2.6-xen-sparse/drivers/xen/fbfront/xenkbd.c | 1 linux-2.6-xen-sparse/drivers/xen/netfront/netfront.c | 1 linux-2.6-xen-sparse/drivers/xen/pcifront/xenbus.c | 1 linux-2.6-xen-sparse/drivers/xen/xenbus/xenbus_probe.c | 25 +++++++++++++++++ 6 files changed, 30 insertions(+), 1 deletion(-)
linux-2.6-xen-sparse/drivers/xen/blkfront/blkfront.c +1 -1
@@ -874,7 +874,7 @@ static struct xenbus_device_id blkfront_ { "vbd" }, { "" } }; - +MODULE_ALIAS ("xen:vbd" );static struct xenbus_driver blkfront = { .name ="vbd" ,
linux-2.6-xen-sparse/drivers/xen/netfront/netfront.c +1 -0
@@ -2075,6 +2075,7 @@ static struct xenbus_device_id netfront_ { "vif" }, { "" } }; +MODULE_ALIAS ("xen:vif" );static struct xenbus_driver netfront = {
linux-2.6-xen-sparse/drivers/xen/xenbus/xenbus_probe.c +25 -0
@@ -165,6 +165,30 @@ static int read_backend_details(struct xreturn read_otherend_details (xendev,"backend-id" ,"backend" ); } +#if LINUX_VERSION_CODE >=KERNEL_VERSION (2 ,6 ,16 ) +static int xenbus_uevent_frontend (struct device *dev,char **envp, +int num_envp,char *buffer,int buffer_size) +{ +struct xenbus_device *xdev; +int length =0 , i =0 ; + +if (dev ==NULL ) +return -ENODEV ; + xdev =to_xenbus_device (dev); +if (xdev ==NULL ) +return -ENODEV ; + +/* stuff we want to pass to /sbin/hotplug */ +add_uevent_var (envp, num_envp, &i, buffer, buffer_size, &length, +"XENBUS_TYPE=%s" , xdev->devicetype); +add_uevent_var (envp, num_envp, &i, buffer, buffer_size, &length, +"XENBUS_PATH=%s" , xdev->nodename); +add_uevent_var (envp, num_envp, &i, buffer, buffer_size, &length, +"MODALIAS=xen:%s" , xdev->devicetype); + +return 0 ; +} +#endif /* Bus type for frontend drivers. */ static struct xen_bus_type xenbus_frontend = {
@@ -180,6 +204,7 @@ static struct xen_bus_type xenbus_fronte .probe = xenbus_dev_probe, .remove = xenbus_dev_remove, .shutdown = xenbus_dev_shutdown, + .uevent = xenbus_uevent_frontend,#endif }, .dev = {
linux-2.6-xen-sparse/drivers/xen/fbfront/xenfb.c +1 -0
@@ -718,6 +718,7 @@ static struct xenbus_device_id xenfb_ids { "vfb" }, { "" } }; +MODULE_ALIAS ("xen:vfb" );static struct xenbus_driver xenfb = { .name ="vfb" ,
linux-2.6-xen-sparse/drivers/xen/fbfront/xenkbd.c +1 -0
@@ -299,6 +299,7 @@ static struct xenbus_device_id xenkbd_id { "vkbd" }, { "" } }; +MODULE_ALIAS ("xen:vkbd" );static struct xenbus_driver xenkbd = { .name ="vkbd" ,
linux-2.6-xen-sparse/drivers/xen/pcifront/xenbus.c +1 -0
@@ -273,6 +273,7 @@ static struct xenbus_device_id xenpci_id {"pci"}, {{0}}, }; +MODULE_ALIAS ("xen:pci" );static struct xenbus_driver xenbus_pcifront_driver = { .name ="pcifront" ,
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 4 lines · Gerd Hoffmann
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
Quoted 7 lines · Jeremy Fitzhardinge
Quoted 4 lines · Gerd Hoffmann
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.
Quoted 2 lines
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
Quoted 2 lines · Gerd Hoffmann
Wow, finally, congratulations.
Thanks. "Now that Xen is upstream" has a certain sound, doesn't it?
Quoted 4 lines
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_opspatch 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.
Quoted 4 lines
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 theparavirt_opsqueue 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