[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH linux-2.6.18-xen] blktap: make max # of tap devices a module parameter



>>> On 23.02.11 at 11:38, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
> Any reason why in .32 and newer you still don't use
> __register_chrdev() (and __unregister_chrdev())? And even
> if this still needs to be this way, I note that unregister_chrdev()
> calls __unregister_chrdev_region() before cdev_del(), while
> blktap_ring_exit() does it the other way around?

I think this could be cleaned up like this:

--- a/drivers/xen/blktap/ring.c
+++ b/drivers/xen/blktap/ring.c
@@ -8,7 +8,6 @@
 #include "blktap.h"
 
 int blktap_ring_major;
-static struct cdev blktap_ring_cdev;
 
  /* 
   * BLKTAP - immediately before the mmap area,
@@ -511,26 +510,16 @@ blktap_ring_debug(struct blktap *tap, ch
 int __init
 blktap_ring_init(void)
 {
-       dev_t dev = 0;
        int err;
 
-       cdev_init(&blktap_ring_cdev, &blktap_ring_file_operations);
-       blktap_ring_cdev.owner = THIS_MODULE;
-
-       err = alloc_chrdev_region(&dev, 0, MAX_BLKTAP_DEVICE, "blktap2");
+       err = __register_chrdev(0, 0, MAX_BLKTAP_DEVICE, "blktap2",
+                               &blktap_ring_file_operations);
        if (err < 0) {
                BTERR("error registering ring devices: %d\n", err);
                return err;
        }
 
-       err = cdev_add(&blktap_ring_cdev, dev, MAX_BLKTAP_DEVICE);
-       if (err) {
-               BTERR("error adding ring device: %d\n", err);
-               unregister_chrdev_region(dev, MAX_BLKTAP_DEVICE);
-               return err;
-       }
-
-       blktap_ring_major = MAJOR(dev);
+       blktap_ring_major = err;
        BTINFO("blktap ring major: %d\n", blktap_ring_major);
 
        return 0;
@@ -542,9 +531,8 @@ blktap_ring_exit(void)
        if (!blktap_ring_major)
                return;
 
-       cdev_del(&blktap_ring_cdev);
-       unregister_chrdev_region(MKDEV(blktap_ring_major, 0),
-                                MAX_BLKTAP_DEVICE);
+       __unregister_chrdev(blktap_ring_major, 0, MAX_BLKTAP_DEVICE,
+                           "blktap2");
 
        blktap_ring_major = 0;
 }

And probably converting MAX_BLKTAP_DEVICE into a configure
option would also be reasonable.

In any case, if I wanted to formally submit patches to clean up
this and some other things in the pv-ops variant, what (preferably
non-topic) branch should those be against? If I'm not mistaken,
xen/next-2.6.38 for example doesn't even have a blktap - or did
it get moved out of drivers/xen/? And what would be the most
up-to-date non-experimental branch to pull blktap bits from?

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.