[PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

[Doug Anderson]

Hi,

On Fri, Apr 29, 2016 at 12:50 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> Your original two arguments don't really stand up.
>
> Let's take #2 to start with.
>
> You claim that coreboot doesn't have support to provide the correct UUID.
> Why is that a problem?  Distros on x86 don't have support to provide the
> correct UUID either.  That's done by the distro when setting the system
> up - it provides the kernel loader (eg, grub) with an appropriate
> configuration, which includes a root specifier with the correct UUID,
> eg:
>
>  root=UUID=a5dcd879-eea2-4d87-bdef-8ee76741e7df
>
> That's for the initramfs to use, but there's a short UUID equivalent for
> the kernel itself, or as Rob and myself have already pointed out, the
> label system (which is problematical if you have multiple filesystems
> with the same label.)  UUID is the better system.

Coreboot certainly has support for this.  It assigns the UUID based on
the disk it gets the kernel for.  If you read my email, you'll see
that it only has a problem when doing TFTP boot.  In this case it
doesn't know which disk to use for a UUID.


> For #1, are you really saying that you're somehow different from all the
> x86 platform users, and can't cope with dynamic numbering of devices that
> are present on x86 systems?

See my other email.  ...and yes, if there is no sane ordering then
you've just got to deal.  ...but there is a sane ordering on many
embedded devices.  If you've got a car and you need to get there fast,
you take the car.  It doesn't matter if other people are biking or
walking.


>> It would be quite easy to adjust this to other systems if they
>> provided similar functionality.  Nearly 100% of this code is just
>> calling helper functions, so the code would be easy to find and change
>> if/when there was a generic (non-DT) method for this.
>
> Except the problem is already solved by the UUID or label mount methods,
> which work everywhere, even across different media.  So, if you decide
> to plug your SD card into a USB reader because the SD slot has become
> unreliable, if you mount by UUID or label, the kernel will still find
> the right device, even though it's now become /dev/sd* instead of
> /dev/mmcblk*.

Not saying UUIDs don't solve problems.  I'm just saying that assigning
consistent numbering shouldn't be hurting you.


>> > If consistent numbering for devices is a goal in the kernel, then I'd
>> > feel otherwise. But I'm pretty sure that is a non-goal.
>>
>> Can you provide documentation that this is a non-goal?  I can submit
>> some patches upstream to make ID allocation behave more randomly if
>> that would be helpful to upstream.  I'd probably want to disable it
>> locally, but if you think folks would really like it...  ;)
>>
>> In all seriousness, though, I'm not sure why randomness in IDs would
>> be considered a worthwhile goal.
>
> *Sigh* you're taking this to an extreme.  Random numbering isn't a goal
> in itself.  The kernel just doesn't provide a _guarantee_ the order in
> which devices appear or the names which the devices will get.
>
> It means that you _can_ mount by device path if you wish, but you may
> occasionally run into cases where the device path changes for one
> reason or another (eg, because you've changed the PCIe card slot that
> your SATA PCIe card is plugged into, or many other reasons.)
>
> Just use UUID (preferred) or label and enjoy much more flexibility than
> your solution adding yet more code to the kernel would give you.

Right.  UUIDs are great.  ...but still seeing nothing that says that
assigning consistent numbering hurts you or hurts UUIDs.

-Doug