mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Olof Johansson <olof@lixom.net>
Cc: linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mmc: make number of mmcblk minors configurable
Date: Wed, 18 Aug 2010 17:16:36 -0700	[thread overview]
Message-ID: <20100818171636.0625b668.akpm@linux-foundation.org> (raw)
In-Reply-To: <20100818041333.GA14149@lixom.net>

On Tue, 17 Aug 2010 23:13:33 -0500
Olof Johansson <olof@lixom.net> wrote:

> The old limit of number of minor numbers per mmcblk device was hardcoded
> at 8. This isn't enough for some of the more elaborate partitioning
> schemes, for example those used by Chrome OS.
> 
> Since there might be a bunch of systems out there with static /dev
> contents that relies on the old numbering scheme, let's make it a
> build-time option with the default set to the previous 8.
> 

How does the numbering scheme change?  What's the user-visible effect
of setting CONFIG_MMC_BLOCK_MINORS to, say, 16?

> ---
>  drivers/mmc/card/Kconfig |   10 ++++++++++
>  drivers/mmc/card/block.c |   20 ++++++++------------
>  2 files changed, 18 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/mmc/card/Kconfig b/drivers/mmc/card/Kconfig
> index 3f2a912..e939dcf 100644
> --- a/drivers/mmc/card/Kconfig
> +++ b/drivers/mmc/card/Kconfig
> @@ -14,6 +14,16 @@ config MMC_BLOCK
>  	  mount the filesystem. Almost everyone wishing MMC support
>  	  should say Y or M here.
>  
> +config MMC_BLOCK_MINORS
> +	int "Number of minors per block device"
> +	range 4 32
> +	default 8
> +	help
> +	  Number of minors per block device. One is needed for every
> +	  partition (plus one for the whole device).
> +	  Default is 8 to be backwards compatible with previous
> +	  hardcoded device numbering.

If possible it would be better to do this with a kernel boot (or
modprobe) parameter.  That permits vendors to ship packaged kernels
with full functionality, etc.  Possible?  The default value of the
runtime-settable parameter could be Kconfigurable is there's a real
need for that.


>  config MMC_BLOCK_BOUNCE
>  	bool "Use bounce buffer for simple hosts"
>  	depends on MMC_BLOCK
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index d545f79..524e232 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -45,13 +45,9 @@
>  
>  MODULE_ALIAS("mmc:block");
>  
> -/*
> - * max 8 partitions per card
> - */
> -#define MMC_SHIFT	3
> -#define MMC_NUM_MINORS	(256 >> MMC_SHIFT)
> +#define MMC_MAX_DEVICES	((255 + CONFIG_MMC_BLOCK_MINORS) / CONFIG_MMC_BLOCK_MINORS)

So if I increase CONFIG_MMC_BLOCK_MINORS, I can no longer support as
many devices?  That'd be worth mentioning somewhere?

fwiw, the above could use DIV_ROUND_UP().



  reply	other threads:[~2010-08-19  0:17 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-18  4:13 Olof Johansson
2010-08-19  0:16 ` Andrew Morton [this message]
2010-08-19  3:22   ` Olof Johansson
2010-08-20  1:02     ` [PATCH v2] mmc: add config and runtime option for number of mmcblk minors Olof Johansson
2010-08-20 22:13       ` [PATCH v3] " Olof Johansson
2010-08-20 22:18         ` sys_init_module system call runcoderen
2010-08-20 22:32           ` Randy Dunlap
2010-08-20 22:50             ` runcoderen
2010-09-08 14:25         ` [PATCH v3] mmc: add config and runtime option for number of mmcblk minors Lei Wen
2010-09-08 14:57           ` Olof Johansson
2010-09-08 15:19             ` Kay Sievers
2010-09-08 15:57               ` Olof Johansson
2010-09-08 16:48                 ` Colin Cross
2010-09-08 16:50                   ` [PATCH] mmc_block: Allow more than 8 partitions per card Colin Cross
2010-09-09  2:49                     ` Lei Wen
2010-09-09  7:54                     ` Adrian Hunter

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=20100818171636.0625b668.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=olof@lixom.net \
    /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

Powered by JetHome