From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: NeilBrown <neilb@suse.com>
Cc: Jens Axboe <axboe@fb.com>,
Maxim Levitsky <maximlevitsky@gmail.com>,
linux-nvdimm@lists.01.org, linux-kernel@vger.kernel.org,
linux-nvme@lists.infradead.org,
Keith Busch <keith.busch@intel.com>
Subject: Re: [PATCH 0/4] Remove un-needed 'major' registration when alloc_disk(0) is used.
Date: Mon, 14 Mar 2016 16:50:17 -0600 [thread overview]
Message-ID: <20160314225017.GC19926@linux.intel.com> (raw)
In-Reply-To: <20160309215702.20904.61407.stgit@noble>
On Thu, Mar 10, 2016 at 08:59:28AM +1100, NeilBrown wrote:
> When alloc_disk(0) is used, the ->major number is ignored and
> irrelevant. Yet several drivers register a major number anyway.
>
> This series of patches removes the pointless registrations. The pmem
> driver also does this, but a patch has already been sent for that
> driver.
>
> Note that I am not in a position to test these beyond simple compile
> testing.
>
> Thanks,
> NeilBrown
>
>
> ---
>
> NeilBrown (4):
> nvdimm/blk: don't allocate unused major device number
> nvdimm/btt: don't allocate unused major device number
> memstick: don't allocate unused major for ms_block
> NVMe: don't allocate unused nvme_major
>
>
> drivers/memstick/core/ms_block.c | 17 ++---------------
> drivers/nvdimm/blk.c | 18 +-----------------
> drivers/nvdimm/btt.c | 19 ++-----------------
> drivers/nvme/host/core.c | 16 +---------------
> 4 files changed, 6 insertions(+), 64 deletions(-)
There are several other drivers that allocate a major, but then use it for
some small number of minors (1 for null_blk.c and 16 for virtio_blk.c). They
both have GENHD_FL_EXT_DEVT set, so I think what happens is that after we
exhaust the allocated minors they hop over to having BLOCK_EXT_MAJOR as a
major and a dynamically assigned minor.
It seems like these could easily be converted in the same way so they'd use
BLOCK_EXT_MAJOR for their major and have a bunch of dynamically assigned
minors.
Does this break something I'm not seeing?
Yay for this series, by the way. :)
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: ross.zwisler@linux.intel.com (Ross Zwisler)
Subject: [PATCH 0/4] Remove un-needed 'major' registration when alloc_disk(0) is used.
Date: Mon, 14 Mar 2016 16:50:17 -0600 [thread overview]
Message-ID: <20160314225017.GC19926@linux.intel.com> (raw)
In-Reply-To: <20160309215702.20904.61407.stgit@noble>
On Thu, Mar 10, 2016@08:59:28AM +1100, NeilBrown wrote:
> When alloc_disk(0) is used, the ->major number is ignored and
> irrelevant. Yet several drivers register a major number anyway.
>
> This series of patches removes the pointless registrations. The pmem
> driver also does this, but a patch has already been sent for that
> driver.
>
> Note that I am not in a position to test these beyond simple compile
> testing.
>
> Thanks,
> NeilBrown
>
>
> ---
>
> NeilBrown (4):
> nvdimm/blk: don't allocate unused major device number
> nvdimm/btt: don't allocate unused major device number
> memstick: don't allocate unused major for ms_block
> NVMe: don't allocate unused nvme_major
>
>
> drivers/memstick/core/ms_block.c | 17 ++---------------
> drivers/nvdimm/blk.c | 18 +-----------------
> drivers/nvdimm/btt.c | 19 ++-----------------
> drivers/nvme/host/core.c | 16 +---------------
> 4 files changed, 6 insertions(+), 64 deletions(-)
There are several other drivers that allocate a major, but then use it for
some small number of minors (1 for null_blk.c and 16 for virtio_blk.c). They
both have GENHD_FL_EXT_DEVT set, so I think what happens is that after we
exhaust the allocated minors they hop over to having BLOCK_EXT_MAJOR as a
major and a dynamically assigned minor.
It seems like these could easily be converted in the same way so they'd use
BLOCK_EXT_MAJOR for their major and have a bunch of dynamically assigned
minors.
Does this break something I'm not seeing?
Yay for this series, by the way. :)
WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: NeilBrown <neilb@suse.com>
Cc: Keith Busch <keith.busch@intel.com>,
Maxim Levitsky <maximlevitsky@gmail.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Jens Axboe <axboe@fb.com>,
Dan Williams <dan.j.williams@intel.com>,
Ross Zwisler <ross.zwisler@linux.intel.com>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-nvdimm@ml01.01.org
Subject: Re: [PATCH 0/4] Remove un-needed 'major' registration when alloc_disk(0) is used.
Date: Mon, 14 Mar 2016 16:50:17 -0600 [thread overview]
Message-ID: <20160314225017.GC19926@linux.intel.com> (raw)
In-Reply-To: <20160309215702.20904.61407.stgit@noble>
On Thu, Mar 10, 2016 at 08:59:28AM +1100, NeilBrown wrote:
> When alloc_disk(0) is used, the ->major number is ignored and
> irrelevant. Yet several drivers register a major number anyway.
>
> This series of patches removes the pointless registrations. The pmem
> driver also does this, but a patch has already been sent for that
> driver.
>
> Note that I am not in a position to test these beyond simple compile
> testing.
>
> Thanks,
> NeilBrown
>
>
> ---
>
> NeilBrown (4):
> nvdimm/blk: don't allocate unused major device number
> nvdimm/btt: don't allocate unused major device number
> memstick: don't allocate unused major for ms_block
> NVMe: don't allocate unused nvme_major
>
>
> drivers/memstick/core/ms_block.c | 17 ++---------------
> drivers/nvdimm/blk.c | 18 +-----------------
> drivers/nvdimm/btt.c | 19 ++-----------------
> drivers/nvme/host/core.c | 16 +---------------
> 4 files changed, 6 insertions(+), 64 deletions(-)
There are several other drivers that allocate a major, but then use it for
some small number of minors (1 for null_blk.c and 16 for virtio_blk.c). They
both have GENHD_FL_EXT_DEVT set, so I think what happens is that after we
exhaust the allocated minors they hop over to having BLOCK_EXT_MAJOR as a
major and a dynamically assigned minor.
It seems like these could easily be converted in the same way so they'd use
BLOCK_EXT_MAJOR for their major and have a bunch of dynamically assigned
minors.
Does this break something I'm not seeing?
Yay for this series, by the way. :)
next prev parent reply other threads:[~2016-03-14 22:51 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-09 21:59 [PATCH 0/4] Remove un-needed 'major' registration when alloc_disk(0) is used NeilBrown
2016-03-09 21:59 ` NeilBrown
2016-03-09 21:59 ` NeilBrown
2016-03-09 21:59 ` [PATCH 4/4] NVMe: don't allocate unused nvme_major NeilBrown
2016-03-09 21:59 ` NeilBrown
2016-03-09 21:59 ` NeilBrown
2016-03-10 9:06 ` Johannes Thumshirn
2016-03-10 9:06 ` Johannes Thumshirn
2016-03-10 9:06 ` Johannes Thumshirn
2016-03-09 21:59 ` [PATCH 2/4] nvdimm/btt: don't allocate unused major device number NeilBrown
2016-03-09 21:59 ` NeilBrown
2016-03-09 21:59 ` NeilBrown
2016-03-10 9:05 ` Johannes Thumshirn
2016-03-10 9:05 ` Johannes Thumshirn
2016-03-10 9:05 ` Johannes Thumshirn
2016-03-09 21:59 ` [PATCH 3/4] memstick: don't allocate unused major for ms_block NeilBrown
2016-03-09 21:59 ` NeilBrown
2016-03-09 21:59 ` NeilBrown
2016-03-10 9:06 ` Johannes Thumshirn
2016-03-10 9:06 ` Johannes Thumshirn
2016-03-10 9:06 ` Johannes Thumshirn
2016-03-09 21:59 ` [PATCH 1/4] nvdimm/blk: don't allocate unused major device number NeilBrown
2016-03-09 21:59 ` NeilBrown
2016-03-09 21:59 ` NeilBrown
2016-03-10 9:05 ` Johannes Thumshirn
2016-03-10 9:05 ` Johannes Thumshirn
2016-03-10 9:05 ` Johannes Thumshirn
2016-03-09 23:35 ` [PATCH 0/4] Remove un-needed 'major' registration when alloc_disk(0) is used Dan Williams
2016-03-09 23:35 ` Dan Williams
2016-03-09 23:35 ` Dan Williams
2016-03-14 22:50 ` Ross Zwisler [this message]
2016-03-14 22:50 ` Ross Zwisler
2016-03-14 22:50 ` Ross Zwisler
2016-03-15 22:15 ` NeilBrown
2016-03-15 22:15 ` NeilBrown
2016-03-15 22:15 ` NeilBrown
2016-03-16 0:20 ` Jens Axboe
2016-03-16 0:20 ` Jens Axboe
2016-03-16 0:20 ` Jens Axboe
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=20160314225017.GC19926@linux.intel.com \
--to=ross.zwisler@linux.intel.com \
--cc=axboe@fb.com \
--cc=keith.busch@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linux-nvme@lists.infradead.org \
--cc=maximlevitsky@gmail.com \
--cc=neilb@suse.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.