[PATCH v4] mtd: super: don't rely on mtdblock device minor
Daniel Golle
daniel at makrotopia.org
Tue May 11 13:17:23 PDT 2021
On Tue, May 11, 2021 at 06:42:48PM +0200, Christoph Hellwig wrote:
> On Tue, May 11, 2021 at 08:57:15AM +0100, Daniel Golle wrote:
> > > Why are you changing the legacy lookup method that is clearly deprecated
> > > in favor of the mdt* syntax?
> >
> > Because it breaks if part_bits != 1 and despite being legacy, it should
> > not break (it would open the wrong MTD device).
>
> Or we should just drop it if it doesn't even work.
It does work for the (most common) case part_bits == 1.
Dropping it is a good option imho, we would need to make changes in
OpenWrt to no longer depend on it, but well, that's life ;)
>
> > I do check the major number above to be MTD_BLOCK_MAJOR, and in that
> > case I assume that my expectations towards private structure will hold
> > true. If not, please enlighten me.
>
> No, you can't. There's always the chance some other driver grabs
> the major. Take a look at what e.g. ubd does to grab the IDE major.
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.
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.
More information about the linux-mtd
mailing list