pmem: don't allocate unused major device number

When alloc_disk(0) or alloc_disk-node(0, XX) is used, the ->major number is completely ignored: all devices are allocated with a major of BLOCK_EXT_MAJOR.

So there is no point allocating pmem_major.

Signed-off-by NeilBrown <[email protected]>

---
 drivers/nvdimm/pmem.c | 19 +------------------
 1 file changed, 1 insertion(+), 18 deletions(-)

Hi Dan et al,
I was recently educating myself about the behavior of alloc_disk(0). As I understand it, the ->major is ignored and all device numbers for all partitions (including '0') are allocated on demand with major number of BLOCK_EXT_MAJOR.

So I was a little surprised to find that pmem.c allocated a major number which is never used - historical anomaly I suspect. I was a bit more surprised at the comment in:

Commit: 9f53f9fa4ad1 ("libnvdimm, pmem: add libnvdimm support to the pmem driver")

"The minor numbers are also more predictable by passing 0 to alloc_disk()."

How can they possibly be more predictable given that they are allocated on-demand? Maybe discovery order is very predictable???

In any case, I propose this patch but cannot test it (beyond compiling) as I don't have relevant hardware. And maybe some user-space code greps /proc/devices for "pmem" to determine if "pmem" is compiled in (though I sincerely hope not).
So I cannot be certain that this patch won't break anything, but am hoping that if you like it you might test it.

Quoted 22 lines · NeilBrown

When alloc_disk(0) or alloc_disk-node(0, XX) is used, the ->major number is completely ignored: all devices are allocated with a major of BLOCK_EXT_MAJOR.

So there is no point allocating pmem_major.

Signed-off-by NeilBrown <[email protected]>

---
 drivers/nvdimm/pmem.c | 19 +------------------
 1 file changed, 1 insertion(+), 18 deletions(-)

Hi Dan et al,
I was recently educating myself about the behavior of alloc_disk(0). As I understand it, the ->major is ignored and all device numbers for all partitions (including '0') are allocated on demand with major number of BLOCK_EXT_MAJOR.

So I was a little surprised to find that pmem.c allocated a major number which is never used - historical anomaly I suspect. I was a bit more surprised at the comment in:

Quoted 6 lines

Commit: 9f53f9fa4ad1 ("libnvdimm, pmem: add libnvdimm support to the pmem driver")

"The minor numbers are also more predictable by passing 0 to alloc_disk()."

How can they possibly be more predictable given that they are allocated on-demand? Maybe discovery order is very predictable???

Ross, I remember you looked into this when Boaz pointed out something similar.

Quoted 6 lines

In any case, I propose this patch but cannot test it (beyond compiling) as I don't have relevant hardware. And maybe some user-space code greps /proc/devices for "pmem" to determine if "pmem" is compiled in (though I sincerely hope not).
So I cannot be certain that this patch won't break anything, but am hoping that if you like it you might test it.

Will do.

Thanks Neil!

When alloc_disk(0) or alloc_disk-node(0, XX) is used, the ->major number is completely ignored: all devices are allocated with a major of BLOCK_EXT_MAJOR.

So there is no point allocating pmem_major.

Signed-off-by NeilBrown <[email protected]>

---
 drivers/nvdimm/pmem.c | 19 +------------------
 1 file changed, 1 insertion(+), 18 deletions(-)

Hi Dan et al,
I was recently educating myself about the behavior of alloc_disk(0). As I understand it, the ->major is ignored and all device numbers for all partitions (including '0') are allocated on demand with major number of BLOCK_EXT_MAJOR.

So I was a little surprised to find that pmem.c allocated a major number which is never used - historical anomaly I suspect. I was a bit more surprised at the comment in:

Commit: 9f53f9fa4ad1 ("libnvdimm, pmem: add libnvdimm support to the pmem driver")

"The minor numbers are also more predictable by passing 0 to alloc_disk()."

How can they possibly be more predictable given that they are allocated on-demand? Maybe discovery order is very predictable???

In any case, I propose this patch but cannot test it (beyond compiling) as I don't have relevant hardware. And maybe some user-space code greps /proc/devices for "pmem" to determine if "pmem" is compiled in (though I sincerely hope not).
So I cannot be certain that this patch won't break anything, but am hoping that if you like it you might test it.

If it does prove acceptable, then similar changes would be appropriate
for btt.c and blk.c. And drivers/memstick/core/ms_block.c and
drivers/nvme/host/core.c. (gotta stamp out this cargo cult)

When alloc_disk(0) or alloc_disk-node(0, XX) is used, the ->major number is completely ignored: all devices are allocated with a major of BLOCK_EXT_MAJOR.

So there is no point allocating pmem_major.

Signed-off-by NeilBrown <[email protected]>

---
 drivers/nvdimm/pmem.c | 19 +------------------
 1 file changed, 1 insertion(+), 18 deletions(-)

Hi Dan et al,
I was recently educating myself about the behavior of alloc_disk(0). As I understand it, the ->major is ignored and all device numbers for all partitions (including '0') are allocated on demand with major number of BLOCK_EXT_MAJOR.

So I was a little surprised to find that pmem.c allocated a major number which is never used - historical anomaly I suspect. I was a bit more surprised at the comment in:

Commit: 9f53f9fa4ad1 ("libnvdimm, pmem: add libnvdimm support to the pmem driver")

"The minor numbers are also more predictable by passing 0 to alloc_disk()."

How can they possibly be more predictable given that they are allocated on-demand? Maybe discovery order is very predictable???

In any case, I propose this patch but cannot test it (beyond compiling) as I don't have relevant hardware. And maybe some user-space code greps /proc/devices for "pmem" to determine if "pmem" is compiled in (though I sincerely hope not).
So I cannot be certain that this patch won't break anything, but am hoping that if you like it you might test it.

If it does prove acceptable, then similar changes would be appropriate
for btt.c and blk.c. And drivers/memstick/core/ms_block.c and
drivers/nvme/host/core.c. (gotta stamp out this cargo cult)

drivers/lightnvm/core.c is the only driver which uses alloc_disk(0) and doesn't provide a 'major' number. :-(

Thanks,
NeilBrown

drivers/nvdimm/pmem.c +1 -18

index 8d0b54670184..ec7e9e6a768e 100644
@@ -47,8 +47,6 @@ struct pmem_device {
 	struct badblocks	bb;
 };
 
-static int pmem_major;
-
 static bool is_bad_pmem(struct badblocks *bb, sector_t sector, unsigned int len)
 {
 	if (bb->count) {

@@ -228,8 +226,6 @@ static int pmem_attach_disk(struct device *dev,
 		return -ENOMEM;
 	}
 
-	disk->major		= pmem_major;
-	disk->first_minor	= 0;
 	disk->fops		= &pmem_fops;
 	disk->private_data	= pmem;
 	disk->queue		= pmem->pmem_queue;

@@ -502,26 +498,13 @@ static struct nd_device_driver nd_pmem_driver = {
 
 static int __init pmem_init(void)
 {
-	int error;
-
-	pmem_major = register_blkdev(0, "pmem");
-	if (pmem_major < 0)
-		return pmem_major;
-
-	error = nd_driver_register(&nd_pmem_driver);
-	if (error) {
-		unregister_blkdev(pmem_major, "pmem");
-		return error;
-	}
-
-	return 0;
+	return nd_driver_register(&nd_pmem_driver);
 }
 module_init(pmem_init);
 
 static void pmem_exit(void)
 {
 	driver_unregister(&nd_pmem_driver.drv);
-	unregister_blkdev(pmem_major, "pmem");
 }
 module_exit(pmem_exit);