Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 29 Sep 2021 21:42:24 +0200
From:   =?utf-8?B?TWljaGHFgiBLxJlwaWXFhA==?= <kernel@kempniu.pl>
To:     Miquel Raynal <miquel.raynal@bootlin.com>
Cc:     Boris Brezillon <boris.brezillon@collabora.com>,
        Richard Weinberger <richard@nod.at>,
        Vignesh Raghavendra <vigneshr@ti.com>,
        linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
        Boris Brezillon <bbrezillon@kernel.org>
Subject: Re: [PATCH] mtd: add MEMREAD ioctl
Message-ID: <YVTBoAnQKYLNpOPc@larwa.hq.kempniu.pl>
References: <20210920070221.10173-1-kernel@kempniu.pl>
 <20210928155859.433844cb@xps13>
 <20210928162402.6bb64fcf@collabora.com>
 <20210928163519.08cd1138@xps13>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20210928163519.08cd1138@xps13>
Precedence: bulk

Miquel, Boris,

Thank you both for your input.

> > I do agree that a new interface is needed, but if we're adding a new
> > entry point, let's make sure it covers all possible use cases we have
> > now. At the very least, I think we're missing info about the maximum
> > number of corrected bits per ECC region on the portion being read.
> > Propagating EUCLEAN errors is nice, but it's not precise enough IMHO.
> > 
> > I remember discussing search a new READ ioctl with Sascha Hauer a few
> > years back, but I can't find the discussion...

I think this is the thread in question:

    https://www.infradead.org/pipermail/linux-mtd/2016-April/thread.html#67085

In fact, it looks like Boris beat me to preparing a draft patch adding a
MEMREAD ioctl by some five years:

    https://www.infradead.org/pipermail/linux-mtd/2016-April/067187.html

It is apparently true that "everything that can be invented has been
invented"... :-)  I did search the web for existing mentions of a
MEMREAD ioctl before submitting my patch, but this thread did not turn
up in the results :(

Anyway, back in 2016, Sascha hinted that he might move forward with the
draft prepared by Boris:

    https://www.infradead.org/pipermail/linux-mtd/2016-April/067215.html

but I cannot find any related submissions from Sascha in linux-mtd's
Patchwork.

> We also discussed a mtd_io_op some time ago, which would equivalently
> replace mtd_oob_ops at some point, including more information such as
> the bitflips which happened on every chunk instead of the information
> regarding the maximum number of bitflips in one of the chunks only.

Is that discussion available online?  Search engines seem to be
oblivious to that term, which makes it hard for me to get acquainted
with that idea and/or to comment on it ;)

> IIRC the point was to get rid of the mtd_{read,write}{,_oob} hooks and
> structures in favor of a more robust and complete set of operations.

That sounds like a major overhaul, right?

I guess the big question from my perspective is: should I revive Boris'
original effort on the MEMREAD ioctl (which returns more detailed
bitflip stats in the structure passed by user space) or would that be a
waste of time because the subsystem will be switched over wholesale to a
new way of doing I/O (mtd_io_op) in the foreseeable future and therefore
exposing yet another ioctl to user space today would be frowned upon?

-- 
Best regards,
Michał Kępień