All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: hch <hch@lst.de>
Cc: Richard Weinberger <richard@nod.at>,
	joern@lazybastard.org, Vignesh Raghavendra <vigneshr@ti.com>,
	linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH] mtd/block2mtd: don't poke into block layer internals
Date: Fri, 15 Oct 2021 08:53:54 +0200	[thread overview]
Message-ID: <20211015085354.5f841f64@xps13> (raw)
In-Reply-To: <20211015062809.GA29769@lst.de>

Hi Richard,

hch@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

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

  reply	other threads:[~2021-10-15  6:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-14 14:52 RFC: decouple block2mtd from block layer internals Christoph Hellwig
2021-10-14 14:52 ` [PATCH] mtd/block2mtd: don't poke into " Christoph Hellwig
2021-10-14 19:28   ` Richard Weinberger
2021-10-15  6:28     ` hch
2021-10-15  6:53       ` Miquel Raynal [this message]
2021-10-19  5:53     ` hch
2021-10-22  7:50       ` Richard Weinberger

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=20211015085354.5f841f64@xps13 \
    --to=miquel.raynal@bootlin.com \
    --cc=hch@lst.de \
    --cc=joern@lazybastard.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    --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.