public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace@gmail.com>
To: Dan Ehrenberg <dehrenberg@chromium.org>
Cc: gwendal@chromium.org, richard.weinberger@gmail.com,
	namnguyen@chromium.org, grundler@chromium.org,
	linux-mtd@lists.infradead.org, ezequiel.garcia@imgtec.com
Subject: Re: [PATCH v2 1/3] mtdpart: Allow adding a partition of a partition
Date: Wed, 4 Mar 2015 11:23:10 -0800	[thread overview]
Message-ID: <20150304192310.GN18140@ld-irv-0074> (raw)
In-Reply-To: <1423609138-19321-1-git-send-email-dehrenberg@chromium.org>

On Tue, Feb 10, 2015 at 02:58:56PM -0800, Dan Ehrenberg wrote:
> MTD allows dynamic partitioning by the BLKPG ioctl.
> The current code restricts partition dynamic addition to work only on
> the master MTD device. This doesn't make a lot of sense, and is
> impossible to meet if the device is already partitioned (since the
> master MTD device is not visible). This commit removes the restriction.
> 
> Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>

The big question I see is whether there is any downside to using
partitions as proxies for the 'master' MTD when adding/deleting
partitions. I think block devices prohibit this, but MTDs are different,
in that we don't always make the master available (i.e., we don't have
/dev/mtda, /dev/mtda1, /dev/mtda2, /dev/mtdb, /dev/mtdb1, ...).

> ---
>  drivers/mtd/mtdchar.c | 4 ----
>  drivers/mtd/mtdpart.c | 6 ++++++
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
> index 5356395..30215c7 100644
> --- a/drivers/mtd/mtdchar.c
> +++ b/drivers/mtd/mtdchar.c
> @@ -545,10 +545,6 @@ static int mtdchar_blkpg_ioctl(struct mtd_info *mtd,
>  	switch (a.op) {
>  	case BLKPG_ADD_PARTITION:
>  
> -		/* Only master mtd device must be used to add partitions */
> -		if (mtd_is_partition(mtd))
> -			return -EINVAL;
> -
>  		/* Sanitize user input */
>  		p.devname[BLKPG_DEVNAMELTH - 1] = '\0';
>  
> diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
> index a3e3a7d..7c6f526 100644
> --- a/drivers/mtd/mtdpart.c
> +++ b/drivers/mtd/mtdpart.c
> @@ -566,6 +566,12 @@ int mtd_add_partition(struct mtd_info *master, const char *name,
>  	if (length <= 0)
>  		return -EINVAL;
>  
> +	if (mtd_is_partition(master)) {
> +		struct mtd_part *master_partition = PART(master);
> +		offset += master_partition->offset;
> +		master = master_partition->master;

One of the problems here is the semantics. Do we really want to do this
offset computation when using the partition instead of the master? That
means if the original partitioning does not cover the early part of the
master MTD, then that piece is lost forever. e.g.,

 master, size 0x1000000, with a single partition
 /dev/mtd0, 1st partition 0x20000 - 0x40000

Then, ioctl(BLKPG, /dev/mtd0) can never create any partitions before
0x20000. But it CAN create partitions after 0x4000! We'd have to support
negative offsets for this to work consistently. (Now that I mention it,
does MTD's BLKPG even do sanity checking on the arguments? I think it
might actually accept negative offsets...)

Also, it's a bit odd that you can use one partition to delete either
another partition, or itself. e.g.,

	flash_part del /dev/mtd1 0  # deletes mtd0
	flash_part del /dev/mtd1 1  # deletes mtd1

This might be acceptable, if awkward. But the first problem looks like
it needs more thought.

> +	}
> +
>  	part.name = name;
>  	part.size = length;
>  	part.offset = offset;

Brian

  parent reply	other threads:[~2015-03-04 19:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-10 22:58 [PATCH v2 1/3] mtdpart: Allow adding a partition of a partition Dan Ehrenberg
2015-02-10 22:58 ` [PATCH v2 2/3] mtdpart: Remove partition overlap checks Dan Ehrenberg
2015-02-10 22:58 ` [PATCH v2 3/3] mtdpart: Allow deleting a partition with another partition as master Dan Ehrenberg
2015-03-03  3:51 ` [PATCH v2 1/3] mtdpart: Allow adding a partition of a partition Daniel Ehrenberg
2015-03-04 19:23 ` Brian Norris [this message]
2015-03-05  1:50   ` Daniel Ehrenberg
2015-03-05  5:33     ` Brian Norris

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=20150304192310.GN18140@ld-irv-0074 \
    --to=computersforpeace@gmail.com \
    --cc=dehrenberg@chromium.org \
    --cc=ezequiel.garcia@imgtec.com \
    --cc=grundler@chromium.org \
    --cc=gwendal@chromium.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=namnguyen@chromium.org \
    --cc=richard.weinberger@gmail.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