Am 27.03.2017 um 18:47 schrieb Matthijs van Duin <matthijsvanduin@gmail.com>:

On 27 March 2017 at 18:32, Tony Lindgren <tony@atomide.com> wrote:
And that's where people will say "use UUIDs" as the Linux
generic solution. Won't help at all making sense of dmesg
output though.

As far as I'm concerned, UUIDs are the last resort of identifiers, since other than being unique they have no desirable trait whatsoever. Moreover the kernel does not even support them last time I checked, so this would force the use of an initramfs.

The mmcblk numbers (with patch) are moreover also useful to unambiguously refer to card slot itself, and the entire block device that resides there. UUIDs are not available for these purposes.

Yes, indeed.

Tony pointed to an interesting aspect:

* we have logical positions and slot descriptions "left SD", "the eMMC", "µSD"

* we have OMAP interface numbers (mmc0, 1, 2) in U-Boot and obviously different ones in kenrel

* the OMAP chip also numbers the interfaces

* linux assigns mmc0...mmcn in some random boot sequence dependent manner

* and if we insert media, we have an UUID for the medium (which is a different piece of hardware than the points above)

So it's the choice between a long obnoxious identifier usable for only a limited subset of use-cases, or a few-line patch to get a short and convenient identifier usable for all purposes. I don't see this as a difficult choice.

I think we all agree that it is a big problem, but the UUID approach has at least the charme to work. Without trying to convince some kernel maintainers to think "embedded"...