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: Thu, 30 Sep 2021 15:54:07 +0200 [thread overview] Message-ID: <YVXBf0v0AQ5+G9dt@larwa.hq.kempniu.pl> (raw) In-Reply-To: <20210930104721.03dc45bb@xps13> > > > > > 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 > > > > Exactly the one I was referring to. Note that this patch still contains > > the unbounded malloc which I think is worth fixing, but other than > > that and the addition of ECC stats, it looks pretty similar to yours. Right, thanks. > > > 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? > > > > > > > That's not my call to make, but I think those 2 things are orthogonal > > and can be addressed separately. > > Agreed. Thank you both - it sounds like I should start working on a v2 that will make the new MEMREAD ioctl return more detailed ECC statistics to user space. Boris, I think a Suggested-by tag crediting you is in order for both the unbounded malloc issue and the MEMREAD ioctl, but submitting-patches.rst says I should not add this tag without your permission. So, are you okay with me adding it? Miquel, as for the unbounded malloc issue, should I address this in a separate (preliminary) patch or rather submit a two-patch v2 series (unbounded malloc fix + new MEMREAD ioctl)? -- 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: Thu, 30 Sep 2021 15:54:07 +0200 [thread overview] Message-ID: <YVXBf0v0AQ5+G9dt@larwa.hq.kempniu.pl> (raw) In-Reply-To: <20210930104721.03dc45bb@xps13> > > > > > 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 > > > > Exactly the one I was referring to. Note that this patch still contains > > the unbounded malloc which I think is worth fixing, but other than > > that and the addition of ECC stats, it looks pretty similar to yours. Right, thanks. > > > 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? > > > > > > > That's not my call to make, but I think those 2 things are orthogonal > > and can be addressed separately. > > Agreed. Thank you both - it sounds like I should start working on a v2 that will make the new MEMREAD ioctl return more detailed ECC statistics to user space. Boris, I think a Suggested-by tag crediting you is in order for both the unbounded malloc issue and the MEMREAD ioctl, but submitting-patches.rst says I should not add this tag without your permission. So, are you okay with me adding it? Miquel, as for the unbounded malloc issue, should I address this in a separate (preliminary) patch or rather submit a two-patch v2 series (unbounded malloc fix + new MEMREAD ioctl)? -- 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-30 13:54 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ń 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ń [this message] 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=YVXBf0v0AQ5+G9dt@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.