[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 Tue, 2011-02-22 at 13:08 -0500, Laszlo Ersek wrote: > On 02/22/11 18:44, Daniel Stodden wrote: > > > I'm pretty sure minors> 256 date way before 2.6.32. Here's the module > > init fragment from blktap2, replacing the register_chrdev() call: > > > > [...] > > That's about what I was thinking of in [0]. It also sets the cdev's owner > manually. However, register_chrdev() also does this: > > 225 kobject_set_name(&cdev->kobj, "%s", name); > 226 for (s = strchr(kobject_name(&cdev->kobj),'/'); s; s = > strchr(s, '/')) > 227 *s = '!'; > > I reckon we can ignore the 's,/,!,g' replacement, since the name is fixed > "blktap" (or "blktap2"). But the kobject name doesn't appear to be set in the > first place. > Is that no problem? If not, I'd just omit it from blktap as well. I remember I browsed a whole lot of code back then when I wrote that. All gone now :) After looking again, I think the way this works was that the kobj map holds the blktap2 class device, nowhere a cdev->kobj, after device_register (blktap2/sysfs.c) actually placed a node for that minor. Before then, only the range is allocated, but won't show up in sysfs. So I guess cdev->kobj is a somewhat anonymous refcount bag only. # l /sys/dev/char/* | grep blktap lrwxrwxrwx 1 root root 0 Feb 22 10:24 /sys/dev/char/10:61 -> ../../class/misc/blktap-control lrwxrwxrwx 1 root root 0 Feb 22 10:24 /sys/dev/char/254:0 -> ../../class/blktap2/blktap0 lrwxrwxrwx 1 root root 0 Feb 22 10:24 /sys/dev/char/254:1 -> ../../class/blktap2/blktap1 lrwxrwxrwx 1 root root 0 Feb 22 10:24 /sys/dev/char/254:2 -> ../../class/blktap2/blktap2 Compare this to the number of tty mappings you'll probably find on your box in the same directory. Daniel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |