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
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
On Tue, Mar 8, 2016 at 2:21 PM, NeilBrown <[email protected]> wrote:
>
> 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???
Ross, I remember you looked into this when Boaz pointed out something similar.
> 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!
On Tue, Mar 08, 2016 at 02:29:58PM -0800, Dan Williams wrote:
> On Tue, Mar 8, 2016 at 2:21 PM, NeilBrown <[email protected]> wrote:
> >
> > 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???
>
> Ross, I remember you looked into this when Boaz pointed out something similar.
I think you're probably remembering a conversation we had about BRD.
https://lkml.org/lkml/2014/8/6/568
I honestly don't remember the details well enough to comment - I'd have to dig
into it again and test to have an informed opinion. But, of course, if we can
get rid of some useless code, we should. :)
> > 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!
On Tue, Mar 8, 2016 at 2:21 PM, NeilBrown <[email protected]> wrote:
>
> 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)
This is passing my tests. Are you going to send these follow-ups as well?
On 03/09/2016 12:21 AM, NeilBrown wrote:
>
> 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]>
Tested-by: Boaz Harrosh <[email protected]>
Yes I sent in the same exact patch several times. This is not the
only driver that has this "wasted code" BTW.
I hope it will be finally removed. Thanks Neil
Boaz
> ---
> 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);
>
>