From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH linux-2.6.18-xen] blktap: make max # of tap devices a module parameter Date: Wed, 23 Feb 2011 10:38:07 +0000 Message-ID: <4D64F19F0200007800033455@vpn.id2.novell.com> References: <4D63C644.1000503@redhat.com> <4D63E918020000780003327C@vpn.id2.novell.com> <4D63F3B7.90108@redhat.com> <1298396687.27394.10.camel@agari.van.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1298396687.27394.10.camel@agari.van.xensource.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Daniel Stodden , Laszlo Ersek Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org >>> On 22.02.11 at 18:44, Daniel Stodden = wrote: > On Tue, 2011-02-22 at 12:34 -0500, Laszlo Ersek wrote: >> On 02/22/11 16:49, Jan Beulich wrote: >> >>>> On 22.02.11 at 15:20, Laszlo Ersek wrote: >> >> Hi, >> >> >> >> should anybody still use the blktap(1) driver in linux-2.6.18-xen, = the >> >> following patch intends to make the maximum number of tapdevs >> >> configurable at module insertion time. The number is clamped to [256 = .. >> >> NR_EVENT_CHANNELS]. I removed the definition of MAX_DEV_NAME because = it >> >> didn't seem to be used at all. >> >> >> >> Thanks for considering, >> >> Laszlo Ersek >> > >> > Without replacing the call to register_chrdev() with one to >> > __register_chrdev() (available only with 2.6.32 and newer) I >> > can't see how you would get beyond 256 devices with the >> > changes you propose. >>=20 >> Oops, sorry; I naively assumed that minor device numbers were already=20= >> covered by an earlier change. >>=20 >> I figure register_chrdev() could be reimplemented in blktap, based = on=20 >> lower-level char_dev.c (and kobject) primitives, but I'm not sure if = the=20 >> original goal is worth that ugliness. In any case, should I bother=20 >> posting a version like that eventually, or would it have no chance = of=20 >> being accepted? >=20 > 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: Sure, just that you have do more things "manually". > int __init > blktap_ring_init(void) > { > dev_t dev =3D 0; > int err; >=20 > cdev_init(&blktap_ring_cdev, &blktap_ring_file_operations); > blktap_ring_cdev.owner =3D THIS_MODULE; >=20 > err =3D alloc_chrdev_region(&dev, 0, MAX_BLKTAP_DEVICE, "blktap2");= > if (err < 0) { > BTERR("error registering ring devices: %d\n", err); > return err; > } >=20 > err =3D 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; > } >=20 > blktap_ring_major =3D MAJOR(dev); > BTINFO("blktap ring major: %d\n", blktap_ring_major); >=20 > return 0; > } 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? Jan