[PATCH 1/1] ubi: Allow ubiblock devices nodes to be created by volume name instead of volume ID.

Richard Weinberger richard.weinberger at gmail.com
Wed Jan 8 14:43:45 PST 2020

On Mon, Dec 30, 2019 at 6:32 PM Ezequiel Garcia
<ezequiel at vanguardiasur.com.ar> wrote:
> Regarding, the "use a initramfs" I've been there, carrying an
> initramfs for the sole purpose of finding the volume with the
> name you want, mounting and pivoting. Looking back,
> I can say this was a big, fat PITA.

It all depends on your tooling. With yocto creating and maintaining
and initramfs is easy.
But maybe I'm a little biased since every single embedded system
I create needs an initramfs due to crypto foo..

> And it's _not_ about boot time or anything like that.
> It's about increasing the number of components
> (in this case, an entire rootfs) that system integrators
> have to maintain, keep track of, and worry about.
> I'm not at all surprised hacking a downstream is easier for
> embedded developers, and I'm sorry we didn't see thought
> about this use case back then.
> > Is it maybe possible to define both /dev/ubiblock%d_%d and
> > /dev/ubiblock%d_%s at the same time?
> Nope, this won't fly.
> The sad news is that it's not easy to fix. The patch proposed
> by Patrick is a no-go, because we don't want to increase
> the number of configuration options for something like this.
> Configuration options increase the combinations that you
> need to test, and so we try to avoid them as much as possible.
> We can't change any default behavior either, as it will
> have an impact on existing systems.
> What we _could_ do, is extend the current syntax, passing
> a format string to the kernel. Something like this, provided
> a ubi0_0 volume, named "rootA".
> ubi.block=0,0,ubiblock${dev.id}_${vol.id}
> would create block device as "/dev/ubiblock0_0".
> Where as, ubi.block=0,0,ubiblock${dev.id}${vol.name}
> would create block device as "/dev/ubiblock0_rootA".
> Knowing Richard's stand in the initramfs camp, I'm sure
> he's eyes are in flames right now :-)
> Does this make any sense... or it is pure insanity?

We need to consider also the volume rename case.
If the kernel creates a named ubiblock device we have to keep
the names consistent also across renames.
Again, udev helps here.

That said, I understand that not everyone wants to have an initramfs.
As maintainer I have to be neutral even when I personally don't like a solution.

I'll happily accept such a change if it:
a) is not an ugly hack and/or makes the existing ubi-naming logic worse
b) is is fine by block layer folks and does not violate the Linux device model

Within UBI we can do whatever we want. That's why the whole ubi name
parsing at attach time exists. IMHO doing this in the kernel was a mistake
and we should have enforced an initramfs back then.
ubiblock is a block device stacked ontop of ubi and we have to obey their rules.


More information about the linux-mtd mailing list