Re: [PATCH v2] mtd: implement proper partition handling

[Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx>]

On Thu, 9 Jan 2020 20:23:58 +0100
Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote:

> Hi Boris,
> 
> Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx> wrote on Thu, 9 Jan
> 2020 20:13:55 +0100:
> 
> > On Thu, 9 Jan 2020 19:45:56 +0100
> > Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote:
> >   
> > > Hi Richard,
> > > 
> > > Richard Weinberger <richard@xxxxxx> 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.

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