linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
To: Dan Williams <dan.j.williams@intel.com>,
	Ross Zwisler <ross.zwisler@linux.intel.com>,
	linux-nvdimm@ml01.01.org, linux-kernel@vger.kernel.org
Subject: [PATCH] pmem: don't allocate unused major device number
Date: Wed, 09 Mar 2016 09:21:54 +1100	[thread overview]
Message-ID: <87k2lclif1.fsf@notabene.neil.brown.name> (raw)

[-- Attachment #1: Type: text/plain, Size: 3040 bytes --]


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 <neilb@suse.com>
---
 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


diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 8d0b54670184..ec7e9e6a768e 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -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);
 
-- 
2.7.2


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

             reply	other threads:[~2016-03-08 22:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-08 22:21 NeilBrown [this message]
2016-03-08 22:29 ` [PATCH] pmem: don't allocate unused major device number Dan Williams
2016-03-09 18:57   ` Ross Zwisler
2016-03-09 19:24 ` Dan Williams
2016-03-20 10:24 ` Boaz Harrosh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k2lclif1.fsf@notabene.neil.brown.name \
    --to=neilb@suse.com \
    --cc=dan.j.williams@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@ml01.01.org \
    --cc=ross.zwisler@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).