From: "Michał Kępień" <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 Date: Wed, 29 Sep 2021 21:42:24 +0200 [thread overview] Message-ID: <YVTBoAnQKYLNpOPc@larwa.hq.kempniu.pl> (raw) In-Reply-To: <20210928163519.08cd1138@xps13> 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ń
WARNING: multiple messages have this Message-ID (diff)
From: "Michał Kępień" <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 Date: Wed, 29 Sep 2021 21:42:24 +0200 [thread overview] Message-ID: <YVTBoAnQKYLNpOPc@larwa.hq.kempniu.pl> (raw) In-Reply-To: <20210928163519.08cd1138@xps13> 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ń ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2021-09-29 19:42 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-20 7:02 [PATCH] mtd: add MEMREAD ioctl Michał Kępień 2021-09-20 7:02 ` Michał Kępień 2021-09-28 13:58 ` Miquel Raynal 2021-09-28 13:58 ` Miquel Raynal 2021-09-28 14:24 ` Boris Brezillon 2021-09-28 14:24 ` Boris Brezillon 2021-09-28 14:35 ` Miquel Raynal 2021-09-28 14:35 ` Miquel Raynal 2021-09-29 19:42 ` Michał Kępień [this message] 2021-09-29 19:42 ` Michał Kępień 2021-09-30 6:51 ` Boris Brezillon 2021-09-30 6:51 ` Boris Brezillon 2021-09-30 8:47 ` Miquel Raynal 2021-09-30 8:47 ` Miquel Raynal 2021-09-30 13:54 ` Michał Kępień 2021-09-30 13:54 ` Michał Kępień 2021-09-30 13:58 ` Miquel Raynal 2021-09-30 13:58 ` Miquel Raynal 2021-09-30 14:22 ` Boris Brezillon 2021-09-30 14:22 ` Boris Brezillon
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=YVTBoAnQKYLNpOPc@larwa.hq.kempniu.pl \ --to=kernel@kempniu.pl \ --cc=bbrezillon@kernel.org \ --cc=boris.brezillon@collabora.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=miquel.raynal@bootlin.com \ --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: linkBe 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.