From: Christoph Hellwig <hch@lst.de>
To: Daniel Golle <daniel@makrotopia.org>
Cc: Christoph Hellwig <hch@lst.de>,
Miquel Raynal <miquel.raynal@bootlin.com>,
linux-mtd@lists.infradead.org,
Vignesh Raghavendra <vigneshr@ti.com>,
Richard Weinberger <richard@nod.at>,
David Woodhouse <dwmw2@infradead.org>, Jan Kara <jack@suse.cz>,
Hannes Reinecke <hare@suse.de>
Subject: Re: [PATCH v4] mtd: super: don't rely on mtdblock device minor
Date: Wed, 12 May 2021 08:42:35 +0200 [thread overview]
Message-ID: <20210512064235.GA19086@lst.de> (raw)
In-Reply-To: <YJrmU6Cw42CZdzAr@makrotopia.org>
On Tue, May 11, 2021 at 09:17:23PM +0100, Daniel Golle wrote:
> IDE with it's 10 majors and a huge load of legacy code involved doesn't
> seem to be the prime example... I generally find *_MAJOR being
> hard-coded via pre-compiler macros and actually quite a lot of code
> seems to make assumptions about the backing driver based on the device
> major number used.
Nothing with many majors. There are valid (but obscure) use cases
where a (new or niche) drivers wants to impersonate an old one. And
the infrastructure allows for that. So guessing from a major number
to a format of private data is absolutely dangerous in the long run
even if it works for trivial setups.
> Anyway, as the same shortcomming (assuming MTD_BLOCK_MAJOR is only used
> by mtdblock driver) also affects the existing code and I'm not aware
> of any other way to check the backing driver, I guess dropping that
> legacy hack is indeed the only good option left.
>
> MTD folks: please advise if you agree that this would be the way
> forward to clean up things for part_bits != 1 to work.
So why do we even depend on the block device code for the legacy
name lookup? Can't we just remove lookup_bdev entirely and just parse
the /dev/mtdblock name here directly without any sort of detour?
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
prev parent reply other threads:[~2021-05-12 6:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-07 21:55 [PATCH] mtd: super: don't reply on mtdblock device minor Daniel Golle
2021-04-08 6:15 ` Miquel Raynal
2021-04-08 20:42 ` [PATCH v2] " Daniel Golle
2021-04-12 15:14 ` [PATCH v3] mtd: super: don't rely " Daniel Golle
2021-05-10 10:18 ` Miquel Raynal
2021-05-10 22:20 ` Daniel Golle
2021-05-10 22:21 ` [PATCH v4] " Daniel Golle
2021-05-11 5:49 ` Christoph Hellwig
2021-05-11 7:57 ` Daniel Golle
2021-05-11 16:42 ` Christoph Hellwig
2021-05-11 20:17 ` Daniel Golle
2021-05-12 6:42 ` Christoph Hellwig [this message]
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=20210512064235.GA19086@lst.de \
--to=hch@lst.de \
--cc=daniel@makrotopia.org \
--cc=dwmw2@infradead.org \
--cc=hare@suse.de \
--cc=jack@suse.cz \
--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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).