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

[Ezequiel Garcia <ezequiel@xxxxxxxxxxxxxxxxxxxx>]

Hello Emil, Patrick, Richard:

I just came across this patch.

On Wed, 14 Aug 2019 at 09:35, Emil Lenngren <emil.lenngren@xxxxxxxxx> wrote:
>
> Hi,
>
> Den tors 4 apr. 2019 kl 21:43 skrev Richard Weinberger <richard@xxxxxx>:
> >
> > Am Donnerstag, 4. April 2019, 17:29:16 CEST schrieb Patrick Doyle:
> > > Add support for CONFIG_MTD_UBI_BLOCK_BY_NAME, which enables ubi block
> > > devices to be named by their volume name: /dev/ubiblock%d_%s rather than
> > > their volume ID /dev/ubiblock%d_%d, so that one can mount e.g. a root
> > > filesystem by UBI name instead of volume ID.  UBI volumes can be renamed
> > > on-the-fly in user space. This allows the root file system to be swapped
> > > from an "A" volume to a "B" volume without having to change the mount
> > > options.
> >
> > Isn't this why we have udev, to create fancy by-id/by-path/... naming conventions?
> >
> > Thanks,
> > //richard
>
> I actually implemented the same change some time ago, for the exact
> same reason (swapping two volumes and then reboot). Referring to an
> ubi volume by name is more convenient than volume numbers, since names
> can be changed and numbers can't.

Arggh, it is such a shame that we missed this when we
designed UBI block!

As you have noticed, atomically changing UBI volume names
is an important UBI feature, extensively used for implementing
safe firmware upgrades.

So, naturally, the device choice should have been based on the
name, and not on the volume ID.

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.

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?

Thanks (also sorry),
Ezequiel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/