Re: (EXT) Re: Consistent block device references for root= cmdline

[Ulf Hansson]

On Thu, 11 Jun 2020 at 13:20, Matthias Schiffer
<matthias.schiffer@xxxxxxxxxxxxxxx> wrote:
>
> On Wed, 2020-06-10 at 16:52 +0200, Ulf Hansson wrote:
> > On Wed, 10 Jun 2020 at 15:15, Matthias Schiffer
> > <matthias.schiffer@xxxxxxxxxxxxxxx> wrote:
> > >
> > > Hello all,
> > >
> > > there have been numerous attempts to make the numbering of mmcblk
> > > devices consistent, mostly by using aliases from the DTS ([1], [2],
> > > [3]), but all have been (rightfully) rejected. Unless I have
> > > overlooked
> > > a more recent development, no attempts for a different solution
> > > were
> > > made.
> >
> > According to aliases attempts, I think those have failed, mainly
> > because of two reasons.
> >
> > 1. Arguments stating that LABELs/UUIDs are variable alternatives.
> > This
> > isn't the case, which I think was also concluded from the several
> > earlier discussions.
> > 2. Patches that tried adding support for mmc aliases, were not
> > correctly coded. More precisely, what needs to be addressed is that
> > the mmc core also preserves the same ids to be set for the host class
> > as the block device, mmc[n] must correspond to mmcblk[n].
> >
> > >
> > > As far as I can tell, the core of the issue seems to be the
> > > following:
> > >
> > > The existing solutions like LABELs and UUIDs are viable
> > > alternatives in
> > > many cases, but in particular on embedded systems, this is not
> > > quite
> > > sufficient: In addition to the problem that more knowledge about
> > > the
> > > system to boot is required in the bootloader, this approach fails
> > > completely when the same firmware image exists on multiple devices,
> > > for
> > > example on an eMMC and an SD card - not an entirely uncommon
> > > situation
> > > during the development of embedded systems.
> > >
> > > With udev, I can refer to a specific partition using a path like
> > > /dev/disk/by-path/platform-2194000.usdhc-part2. In [4] it was
> > > proposed
> > > to add a way to refer to a device path/phandle from the kernel
> > > command
> > > line. Has there been any progress on this proposal?
> >
> > Lots of time during the years I have been approached, both publicly
> > and offlist, about whether it would be possible to add support for
> > "consistent" mmcblk devices. To me, I am fine with the aliases
> > approach, as long as it gets implemented correctly.
>
>
> It seems the principal technical problem is the one described here:
>
> https://www.spinics.net/lists/linux-mmc/msg26602.html
>
> I don't see any way to solve this completely, as there seem to be two
> fundamentally conflicting requirements:
>
> 1) If a mounted SD card is replaced, it must be assigned a new
> /dev/mmcblkN
> 2) /dev/mmcblkN should always match the configured alias IDs
>
> What is the reason we need 1) - is it possible to have multiple eMMCs
> or SD cards on a single bus, with detection at runtime?

Yes. The mmc_bus_type holds all cards - all discovered at runtime.

> Otherwise I'd
> expect this to be handled like other drives with removable media (CD,
> floppy), with static device assignment.
>
> If we can't give up on 1) for some reason, we'll have to accept that we
> can't guarantee 2) unconditionally. As far as I can tell, the patches
> provided by Sascha and others did that in a reasonable way: The aliases
> would work in most cases - in particular for the first assignment on
> boot, which is required to find the correct rootfs.

Well, if we would pre-parse the DTB to look for all "mmc block
aliases" and keep a mark of those ids as being reserved, then we
should be able to cope with both 1) and 2).

>
> >
> > >
> > > Kind regards,
> > > Matthias
> > >
> > >
> > > [1] https://patchwork.kernel.org/patch/8685711/
> > > [2] https://lore.kernel.org/patchwork/cover/674381/
> > > [3] https://www.spinics.net/lists/linux-mmc/msg26586.html
> > > [4] https://www.spinics.net/lists/linux-mmc/msg26708.html
> > >
> >

Kind regards
Uffe