All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Richard Weinberger <richard@nod.at>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Tudor Ambarus <Tudor.Ambarus@microchip.com>
Subject: Re: [PATCH v2] mtd: implement proper partition handling
Date: Fri, 10 Jan 2020 09:28:55 +0100	[thread overview]
Message-ID: <20200110092855.79f18339@xps13> (raw)
In-Reply-To: <20200109203722.4423ed09@collabora.com>

Hi Boris,

Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 9 Jan
2020 20:37:22 +0100:

> On Thu, 9 Jan 2020 20:23:58 +0100
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> 
> > Hi Boris,
> > 
> > Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 9 Jan
> > 2020 20:13:55 +0100:
> >   
> > > On Thu, 9 Jan 2020 19:45:56 +0100
> > > Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >     
> > > > Hi Richard,
> > > > 
> > > > Richard Weinberger <richard@nod.at> wrote on Thu, 9 Jan 2020 19:43:04
> > > > +0100 (CET):
> > > >       
> > > > > Miquel,
> > > > > 
> > > > > ----- Ursprüngliche Mail -----        
> > > > > >> What problem does this solve?
> > > > > >> ...beside of a nice diffstat which removes more than it adds. :-)          
> > > > > > 
> > > > > > It is much easier to escalade to the top most "master" device when
> > > > > > there are multiple levels of partitioning, which was not cleanly
> > > > > > described IMHO. Also it is already used in the MLC-in-pseudo-SLC-mode
> > > > > > series :)          
> > > > > 
> > > > > Ok. In fact I "found" this patch my looking at the SLC emulation patches.
> > > > >         
> > > > > >> > +static inline struct mtd_info *mtd_get_master(struct mtd_info *mtd)
> > > > > >> > +{
> > > > > >> > +	while (mtd->parent)
> > > > > >> > +		mtd = mtd->parent;
> > > > > >> > +
> > > > > >> > +	return mtd;
> > > > > >> > +}          
> > > > > >> 
> > > > > >> So, parent == master?          
> > > > > > 
> > > > > > top most parent (the one without parent) == master !
> > > > > >           
> > > > > >> 
> > > > > >> When I create a MTD ontop of UBI using gluebi, who will be parent/master?          
> > > > > > 
> > > > > > I don't really understand the issue here?          
> > > > > 
> > > > > Let's say I have mtd0 with an ubi and a volume "xxx". After enabling
> > > > > gluebi a new mtd1 will arrive on the system.
> > > > > The stacking is mtd0 -> ubi (volume xxx) -> mtd1.        
> > > > 
> > > > This is much clearer, thanks!
> > > >       
> > > > > Is now a relationship between mtd1 and mtd0?        
> > > > 
> > > > No there is none. 
> > > >       
> > > > > I'd expect mtd1's parent being mtd0.        
> > > > 
> > > > This would be a new feature, right? I don't think it is the case today.      
> > > 
> > > We definitely don't want mtd1 to appear as a partition of mtd0 in that
> > > case (blocks in mtd1 can't be mapped to blocks in mtd0 without the UBI
> > > layer being involved). Maybe it'd be clearer if we move the parent
> > > field to mtd_part and add an MTD_IS_PARTITION flag. Or maybe we can
> > > just choose a better name.    
> > 
> > I prefer the name change. I think the current struct organization
> > is right. What do you suggest?  
> 
> I don't have a better name, sorry.

Actually I find ->parent totally descriptive, and in Richard's example,
I would not call mtd1 as mtd0's parent, it's more like a "top virtual
device" but certainly not a "direct" parent.

mtd->direct_parent would work but I think it is a bit too long and most
of the people would not understand why we call it this way, instead of
just "parent".

I would like to take this patch into 5.6, so please tell me what you
prefer ("parent" being the most straightforward and simple solution to
me :) )

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2020-01-10  8:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-30 11:19 [PATCH v2] mtd: implement proper partition handling Miquel Raynal
2020-01-08 23:34 ` Richard Weinberger
2020-01-09 18:13   ` Miquel Raynal
2020-01-09 18:43     ` Richard Weinberger
2020-01-09 18:45       ` Miquel Raynal
2020-01-09 19:13         ` Boris Brezillon
2020-01-09 19:23           ` Miquel Raynal
2020-01-09 19:37             ` Boris Brezillon
2020-01-10  8:28               ` Miquel Raynal [this message]
2020-01-10  9:46                 ` Boris Brezillon
2020-01-10  9:55                   ` Miquel Raynal

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=20200110092855.79f18339@xps13 \
    --to=miquel.raynal@bootlin.com \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=boris.brezillon@collabora.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=vigneshr@ti.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.