[PATCH] mtd/block2mtd: don't poke into block layer internals

[Miquel Raynal]

Hi Richard,

hch at lst.de wrote on Fri, 15 Oct 2021 08:28:09 +0200:

> On Thu, Oct 14, 2021 at 09:28:19PM +0200, Richard Weinberger wrote:
> > > instead.  Note that this contains a small behavior change in that erase
> > > now unconditionally writes all Fs instead of first scanning for them.  
> > 
> > Unless you have a strong opinoin I'd like to keep the scanning.
> > The original use case of block2mtd is using Compact Flash (ATA)
> > as MTD. Some of this devices are super stupid and I fear the 0xFF scanning
> > is here to avoid programming 0xFF bytes into the NAND.
> > Just to be on the safe side...  
> 
> Hmm.  Doing the right first is quite a bit of overhead, especially as
> unlike the direct page cache access we can't just poke into the page
> without copying it.
> 
> > I think we can actually weaken that check to allow regular files too.
> > Then one can directly use a file as backend. These days people use block2mtd
> > sometimes with a file backend via a loop device.  
> 
> Yes, a file backend will work just fine.
> 
> > P.s: While reading this driver I found another issue. There is no way to remove an MTD at runtime.
> > Miquel, what do you think? Shall we limit block2mtd to one MTD?
> > The current interface via module parameters is horrible.

I believe if we do this we will someday find someone who *wants*
several block2mtd devices and we'll be back to today's situation.

What about an extra parameter where you provide the mtd device to
remove it? Or perhaps a new interface if block2mtd is actually used
in another pseudo-fs? (like configfs or perhaps debugfs if this is
suitable)

Thanks,
Miquèl