Hi,

On Fri, Apr 29, 2016 at 12:50 PM, Russell King - ARM Linux
[off-list ref] 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.

quoted

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.

quoted

quoted

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