Discussion:
[PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree
(too old to reply)
Douglas Anderson
2016-04-29 17:32:15 UTC
Permalink
This series picks patches from various different places to produce what
I consider the best solution to getting consistent mmc and mmcblk
ordering.

Why consistent ordering and why not just use UUIDs? IMHO consistent
ordering solves a few different problems:

1. For poor, feeble-minded humans like me, have sane numbering for
devices helps a lot. When grepping through dmesg it's terribly handy
if a given SDMMC device has a consistent number. I know that I can
do "dmesg | grep mmc0" or "dmesg | grep mmcblk0" to find info about
the eMMC. I know that I can do "dmesg | grep mmc1" to find info
about the SD card slot. I don't want it to matter which one probed
first, I don't want it to matter if I'm working on a variant of the
hardware that has the SD card slot disabled, and I don't want to care
what my boot device was. Worrying about what device number I got
increases my cognitive load.

2. There are cases where it's not trivially easy during development to
use the UUID. Specifically I work a lot with coreboot / depthcharge
as a BIOS. When configured properly, that BIOS has a nice feature to
allow you to fetch the kernel and kernel command line from TFTP by
pressing Ctrl-N. In this particular case the BIOS doesn't actually
know which disk I'd like for my root filesystem, so it's not so easy
for it to put the right UUID into the command line. For this
purpose, knowing that "mmcblk0" will always refer to eMMC is handy.

Changes in v2:
- Rebased atop mmc-next
- Stat dynamic allocation after fixed allocation; thanks Wolfram!
- rk3288 patch new for v2

Douglas Anderson (1):
ARM: dts: rockchip: Add mmc aliases for rk3288 platform

Jaehoon Chung (1):
Documentation: mmc: Document mmc aliases

Stefan Agner (2):
mmc: read mmc alias from device tree
mmc: use SD/MMC host ID for block device name ID

Documentation/devicetree/bindings/mmc/mmc.txt | 11 +++++++++++
arch/arm/boot/dts/rk3288.dtsi | 4 ++++
drivers/mmc/card/block.c | 2 +-
drivers/mmc/core/host.c | 17 ++++++++++++++++-
4 files changed, 32 insertions(+), 2 deletions(-)
--
2.8.0.rc3.226.g39d4020
Douglas Anderson
2016-04-29 17:32:19 UTC
Permalink
Now that mmc aliases are officially in bindings, add them to rk3288.
This could be done to lots of platforms, but this is the one I tested
with.

Signed-off-by: Douglas Anderson <***@chromium.org>
---
Changes in v2:
- rk3288 patch new for v2

arch/arm/boot/dts/rk3288.dtsi | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 31f7e20ef418..4cb15dcd1c1e 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -60,6 +60,10 @@
i2c3 = &i2c3;
i2c4 = &i2c4;
i2c5 = &i2c5;
+ mmc0 = &emmc;
+ mmc1 = &sdmmc;
+ mmc2 = &sdio0;
+ mmc3 = &sdio1;
mshc0 = &emmc;
mshc1 = &sdmmc;
mshc2 = &sdio0;
--
2.8.0.rc3.226.g39d4020
Rob Herring
2016-04-29 18:12:30 UTC
Permalink
On Fri, Apr 29, 2016 at 12:32 PM, Douglas Anderson
Post by Douglas Anderson
This series picks patches from various different places to produce what
I consider the best solution to getting consistent mmc and mmcblk
ordering.
Why consistent ordering and why not just use UUIDs? IMHO consistent
1. For poor, feeble-minded humans like me, have sane numbering for
devices helps a lot. When grepping through dmesg it's terribly handy
if a given SDMMC device has a consistent number. I know that I can
do "dmesg | grep mmc0" or "dmesg | grep mmcblk0" to find info about
the eMMC. I know that I can do "dmesg | grep mmc1" to find info
about the SD card slot. I don't want it to matter which one probed
first, I don't want it to matter if I'm working on a variant of the
hardware that has the SD card slot disabled, and I don't want to care
what my boot device was. Worrying about what device number I got
increases my cognitive load.
2. There are cases where it's not trivially easy during development to
use the UUID. Specifically I work a lot with coreboot / depthcharge
as a BIOS. When configured properly, that BIOS has a nice feature to
allow you to fetch the kernel and kernel command line from TFTP by
pressing Ctrl-N. In this particular case the BIOS doesn't actually
know which disk I'd like for my root filesystem, so it's not so easy
for it to put the right UUID into the command line. For this
purpose, knowing that "mmcblk0" will always refer to eMMC is handy.
Why don't you use labels? This works whether your rootfs is on
/dev/vdXy, /dev/sdXy or /dev/mmcblkXpy. I can feel your pain as I've
been looking at the per device crap that is Android fstab files which
labels solve beautifully and worked without Android changes.

Sorry, I'm not keen to add something that is both MMC and DT specific.
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.

Aliases were largely intended for backwards compatibility in cases
where the numbering was already consistent (IOW consoles).

Rob
Doug Anderson
2016-04-29 19:31:28 UTC
Permalink
Rob,
Post by Rob Herring
On Fri, Apr 29, 2016 at 12:32 PM, Douglas Anderson
Post by Douglas Anderson
This series picks patches from various different places to produce what
I consider the best solution to getting consistent mmc and mmcblk
ordering.
Why consistent ordering and why not just use UUIDs? IMHO consistent
1. For poor, feeble-minded humans like me, have sane numbering for
devices helps a lot. When grepping through dmesg it's terribly handy
if a given SDMMC device has a consistent number. I know that I can
do "dmesg | grep mmc0" or "dmesg | grep mmcblk0" to find info about
the eMMC. I know that I can do "dmesg | grep mmc1" to find info
about the SD card slot. I don't want it to matter which one probed
first, I don't want it to matter if I'm working on a variant of the
hardware that has the SD card slot disabled, and I don't want to care
what my boot device was. Worrying about what device number I got
increases my cognitive load.
2. There are cases where it's not trivially easy during development to
use the UUID. Specifically I work a lot with coreboot / depthcharge
as a BIOS. When configured properly, that BIOS has a nice feature to
allow you to fetch the kernel and kernel command line from TFTP by
pressing Ctrl-N. In this particular case the BIOS doesn't actually
know which disk I'd like for my root filesystem, so it's not so easy
for it to put the right UUID into the command line. For this
purpose, knowing that "mmcblk0" will always refer to eMMC is handy.
Why don't you use labels? This works whether your rootfs is on
/dev/vdXy, /dev/sdXy or /dev/mmcblkXpy.
I've never used labels. I can take a look at them. I presume I'll
have to do a little extra work to tag my "emmc" filesystem properly
when I install to eMMC, but that wouldn't be too bad. Thanks for the
suggestion.

That solves point #2, but not point #1. It still adds an extra step
of mapping number to device when looking at logs / sysfs files.

IMHO:

* this patch set is very small.

* this patch set doesn't hurt anyone.

* I believe lots of people feel that this patch set would be useful.

* this patch set is very small and shouldn't be too hard to maintain.

* the MMC maintainer, who would be responsible for dealing with the
code in the future if any problems come up, seem to be OK with it.
Post by Rob Herring
I can feel your pain as I've
been looking at the per device crap that is Android fstab files which
labels solve beautifully and worked without Android changes.
Sorry, I'm not keen to add something that is both MMC and DT specific.
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.

As far as it being MMC specific: it's not. Do a "git grep" for
of_alias_get_id(). It's used in many, many places.
Post by Rob Herring
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. Is it because:

* You're trying to discourage people from building systems where they
hardcode "/dev/mmcblk0" as the eMMC? Maybe it would be better to
throw a big WARN_ON in the boot log for this?

* You think that numbering like this doesn't scale somehow? Note that
for a given piece of hardware it's quite likely to have a small number
of MMC slots and it's quite likely that users of this SoC can agree on
the numbering (emmc = 0, SD slots start at 1).

* Some other reason?


-Doug
Russell King - ARM Linux
2016-04-29 19:50:08 UTC
Permalink
Post by Doug Anderson
Rob,
Post by Rob Herring
On Fri, Apr 29, 2016 at 12:32 PM, Douglas Anderson
Post by Douglas Anderson
This series picks patches from various different places to produce what
I consider the best solution to getting consistent mmc and mmcblk
ordering.
Why consistent ordering and why not just use UUIDs? IMHO consistent
1. For poor, feeble-minded humans like me, have sane numbering for
devices helps a lot. When grepping through dmesg it's terribly handy
if a given SDMMC device has a consistent number. I know that I can
do "dmesg | grep mmc0" or "dmesg | grep mmcblk0" to find info about
the eMMC. I know that I can do "dmesg | grep mmc1" to find info
about the SD card slot. I don't want it to matter which one probed
first, I don't want it to matter if I'm working on a variant of the
hardware that has the SD card slot disabled, and I don't want to care
what my boot device was. Worrying about what device number I got
increases my cognitive load.
2. There are cases where it's not trivially easy during development to
use the UUID. Specifically I work a lot with coreboot / depthcharge
as a BIOS. When configured properly, that BIOS has a nice feature to
allow you to fetch the kernel and kernel command line from TFTP by
pressing Ctrl-N. In this particular case the BIOS doesn't actually
know which disk I'd like for my root filesystem, so it's not so easy
for it to put the right UUID into the command line. For this
purpose, knowing that "mmcblk0" will always refer to eMMC is handy.
Why don't you use labels? This works whether your rootfs is on
/dev/vdXy, /dev/sdXy or /dev/mmcblkXpy.
I've never used labels. I can take a look at them. I presume I'll
have to do a little extra work to tag my "emmc" filesystem properly
when I install to eMMC, but that wouldn't be too bad. Thanks for the
suggestion.
That solves point #2, but not point #1. It still adds an extra step
of mapping number to device when looking at logs / sysfs files.
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.

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?
Post by Doug Anderson
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*.
Post by Doug Anderson
Post by Rob Herring
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.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
Doug Anderson
2016-04-29 20:02:14 UTC
Permalink
Hi,

On Fri, Apr 29, 2016 at 12:50 PM, Russell King - ARM Linux
Post by Russell King - ARM Linux
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,
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.
Post by Russell King - ARM Linux
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.
Post by Russell King - ARM Linux
Post by Doug Anderson
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.
Post by Russell King - ARM Linux
Post by Doug Anderson
Post by Rob Herring
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
Russell King - ARM Linux
2016-04-29 18:12:48 UTC
Permalink
Post by Douglas Anderson
This series picks patches from various different places to produce what
I consider the best solution to getting consistent mmc and mmcblk
ordering.
Why consistent ordering and why not just use UUIDs? IMHO consistent
NAK. Really. Use UUIDs, that's the proper solution here.

Exactly the same issue arises if you have more than one ATA or SCSI
adapter in your PC - things can be probed out of order and end up
in different /dev/sd* slots.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
Doug Anderson
2016-04-29 19:43:39 UTC
Permalink
Russell,

On Fri, Apr 29, 2016 at 11:12 AM, Russell King - ARM Linux
Post by Russell King - ARM Linux
Post by Douglas Anderson
This series picks patches from various different places to produce what
I consider the best solution to getting consistent mmc and mmcblk
ordering.
Why consistent ordering and why not just use UUIDs? IMHO consistent
NAK. Really. Use UUIDs, that's the proper solution here.
Un-NAK. UUIDs don't solve point #1.
Post by Russell King - ARM Linux
Exactly the same issue arises if you have more than one ATA or SCSI
adapter in your PC - things can be probed out of order and end up
in different /dev/sd* slots.
Yup, UUIDs are awesome and great and super. Best invention since
sliced bread, really. I definitely _won't_ submit a patch to remove
UUID support. I promise.

A few notes, though:

* Presumably on a PC you've got an extra bit in the middle (like grub
or something like that) that can help you resolve your UUIDs even if
you get your kernel from somewhere else. In my case, I don't have
that. Maybe this is a failing of coreboot / depthcharge's netboot and
I suppose. ...and I suppose I could modify the BIOS to take a root
filesystem of "eMMC" and have it resolve that to the eMMC's UUID or
something like that. ...or I just take these patches locally and
things keep working like they did before.

* Presumably in the non-embedded world kernel hackers have a different
workflow. They probably don't swap between different devices with
different configurations on an hourly basis. They're not in the habit
of totally reimaging their system periodically. Etc. Trying to force
the workflow of a PC kernel hacker and an embedded kernel hacker to be
the same doesn't seem like a worthwhile goal.

* Presumably an embedded kernel hacker running with ATA / SCSI could
_usually_ assume that "sda" is his/her root filesystem. It's unlikely
an embedded system would have more than one "sda" disk builtin and
it's nearly guaranteed (I think) that a builtin ATA / SCSI controller
would probe before any USB based devices. Sure, if your root
filesystem is USB based (really?) and you've got additional USB
storage devices then you're SOL. Sorry.

-Doug
Russell King - ARM Linux
2016-04-29 19:57:41 UTC
Permalink
Post by Doug Anderson
Russell,
On Fri, Apr 29, 2016 at 11:12 AM, Russell King - ARM Linux
Post by Russell King - ARM Linux
Post by Douglas Anderson
This series picks patches from various different places to produce what
I consider the best solution to getting consistent mmc and mmcblk
ordering.
Why consistent ordering and why not just use UUIDs? IMHO consistent
NAK. Really. Use UUIDs, that's the proper solution here.
Un-NAK. UUIDs don't solve point #1.
Re-NAK. I don't think your point #1 is valid. See my other reply.
Post by Doug Anderson
* Presumably on a PC you've got an extra bit in the middle (like grub
or something like that) that can help you resolve your UUIDs even if
you get your kernel from somewhere else.
You are over-estimating what grub does. Grub doesn't resolve UUIDs at
all. Grub just passes the kernel arguments in its configuration file
for the entry it is booting to the kernel. It's a static configuration
found in /boot/grub/grub.conf.

It doesn't probe devices for UUIDs.
Post by Doug Anderson
* Presumably in the non-embedded world kernel hackers have a different
workflow. They probably don't swap between different devices with
different configurations on an hourly basis. They're not in the habit
of totally reimaging their system periodically. Etc. Trying to force
the workflow of a PC kernel hacker and an embedded kernel hacker to be
the same doesn't seem like a worthwhile goal.
In _my_ world with the "embedded" devices I have, I mount by UUID on
platforms which have multiple MMC devices to avoid exactly the problem
you're having. This works fine.

If I were to switch the SD card, and I wanted to avoid changing the
boot loader configuration, I'd use label instead, and I'd label all
the SD card rootfs using the same label so I could just swap the cards.
Post by Doug Anderson
* Presumably an embedded kernel hacker running with ATA / SCSI could
_usually_ assume that "sda" is his/her root filesystem. It's unlikely
an embedded system would have more than one "sda" disk builtin and
it's nearly guaranteed (I think) that a builtin ATA / SCSI controller
would probe before any USB based devices.
You've got a funny view again. N2100 has two hard disks. The clearfog
board from SolidRun has two mini-PCIe slots, each of which can have two
SATA interfaces... If you want to use it as a server-type platform with
lots of disks...
Post by Doug Anderson
Sure, if your root
filesystem is USB based (really?) and you've got additional USB
storage devices then you're SOL. Sorry.
One of my Versatile Express platforms boots from USB, and has a MMC
slot... So this argument does not stack up.

Sorry.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
Doug Anderson
2016-04-29 20:04:48 UTC
Permalink
Russell,

On Fri, Apr 29, 2016 at 12:57 PM, Russell King - ARM Linux
Post by Russell King - ARM Linux
Post by Doug Anderson
* Presumably on a PC you've got an extra bit in the middle (like grub
or something like that) that can help you resolve your UUIDs even if
you get your kernel from somewhere else.
You are over-estimating what grub does. Grub doesn't resolve UUIDs at
all. Grub just passes the kernel arguments in its configuration file
for the entry it is booting to the kernel. It's a static configuration
found in /boot/grub/grub.conf.
It doesn't probe devices for UUIDs.
OK. The point was: if folks on PCs have a workflow that works for
them, wonderful. That workflow doesn't work so great for me. My
workflow doesn't hurt them. Why is it bad?
Post by Russell King - ARM Linux
Post by Doug Anderson
* Presumably in the non-embedded world kernel hackers have a different
workflow. They probably don't swap between different devices with
different configurations on an hourly basis. They're not in the habit
of totally reimaging their system periodically. Etc. Trying to force
the workflow of a PC kernel hacker and an embedded kernel hacker to be
the same doesn't seem like a worthwhile goal.
In _my_ world with the "embedded" devices I have, I mount by UUID on
platforms which have multiple MMC devices to avoid exactly the problem
you're having. This works fine.
If I were to switch the SD card, and I wanted to avoid changing the
boot loader configuration, I'd use label instead, and I'd label all
the SD card rootfs using the same label so I could just swap the cards.
OK. The point was: if you have a workflow that works for you,
wonderful. That workflow doesn't work so great for me. My workflow
doesn't hurt you. Why is it bad?
Post by Russell King - ARM Linux
Post by Doug Anderson
* Presumably an embedded kernel hacker running with ATA / SCSI could
_usually_ assume that "sda" is his/her root filesystem. It's unlikely
an embedded system would have more than one "sda" disk builtin and
it's nearly guaranteed (I think) that a builtin ATA / SCSI controller
would probe before any USB based devices.
You've got a funny view again. N2100 has two hard disks. The clearfog
board from SolidRun has two mini-PCIe slots, each of which can have two
SATA interfaces... If you want to use it as a server-type platform with
lots of disks...
OK. The point was: if you have a workflow that works for you,
wonderful. That workflow doesn't work so great for me. My workflow
doesn't hurt you. Why is it bad?
Post by Russell King - ARM Linux
Post by Doug Anderson
Sure, if your root
filesystem is USB based (really?) and you've got additional USB
storage devices then you're SOL. Sorry.
One of my Versatile Express platforms boots from USB, and has a MMC
slot... So this argument does not stack up.
OK. The point was: if you have a workflow that works for you,
wonderful. That workflow doesn't work so great for me. My workflow
doesn't hurt you. Why is it bad?


-Doug
Russell King - ARM Linux
2016-04-29 21:13:28 UTC
Permalink
Post by Doug Anderson
Russell,
On Fri, Apr 29, 2016 at 12:57 PM, Russell King - ARM Linux
Post by Russell King - ARM Linux
Post by Doug Anderson
* Presumably on a PC you've got an extra bit in the middle (like grub
or something like that) that can help you resolve your UUIDs even if
you get your kernel from somewhere else.
You are over-estimating what grub does. Grub doesn't resolve UUIDs at
all. Grub just passes the kernel arguments in its configuration file
for the entry it is booting to the kernel. It's a static configuration
found in /boot/grub/grub.conf.
It doesn't probe devices for UUIDs.
OK. The point was: if folks on PCs have a workflow that works for
them, wonderful. That workflow doesn't work so great for me. My
workflow doesn't hurt them. Why is it bad?
This discussion is over, since you're not willing to actually discuss
it (illustrated by you cutting and pasting this same thing four
times in your reply.)

My NAK stands until such time that you can partake in a reasonable
discussion.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
Doug Anderson
2016-04-29 21:17:45 UTC
Permalink
Hi,

On Fri, Apr 29, 2016 at 2:13 PM, Russell King - ARM Linux
Post by Russell King - ARM Linux
Post by Doug Anderson
Russell,
On Fri, Apr 29, 2016 at 12:57 PM, Russell King - ARM Linux
Post by Russell King - ARM Linux
Post by Doug Anderson
* Presumably on a PC you've got an extra bit in the middle (like grub
or something like that) that can help you resolve your UUIDs even if
you get your kernel from somewhere else.
You are over-estimating what grub does. Grub doesn't resolve UUIDs at
all. Grub just passes the kernel arguments in its configuration file
for the entry it is booting to the kernel. It's a static configuration
found in /boot/grub/grub.conf.
It doesn't probe devices for UUIDs.
OK. The point was: if folks on PCs have a workflow that works for
them, wonderful. That workflow doesn't work so great for me. My
workflow doesn't hurt them. Why is it bad?
This discussion is over, since you're not willing to actually discuss
it (illustrated by you cutting and pasting this same thing four
times in your reply.)
My NAK stands until such time that you can partake in a reasonable
discussion.
The point of pasting it several times was that you'd answer it.
Apparently that failed.

Perhaps you could answer the question I posed?

-Doug
Russell King - ARM Linux
2016-04-29 21:29:20 UTC
Permalink
Post by Doug Anderson
Hi,
On Fri, Apr 29, 2016 at 2:13 PM, Russell King - ARM Linux
Post by Russell King - ARM Linux
Post by Doug Anderson
Russell,
On Fri, Apr 29, 2016 at 12:57 PM, Russell King - ARM Linux
Post by Russell King - ARM Linux
Post by Doug Anderson
* Presumably on a PC you've got an extra bit in the middle (like grub
or something like that) that can help you resolve your UUIDs even if
you get your kernel from somewhere else.
You are over-estimating what grub does. Grub doesn't resolve UUIDs at
all. Grub just passes the kernel arguments in its configuration file
for the entry it is booting to the kernel. It's a static configuration
found in /boot/grub/grub.conf.
It doesn't probe devices for UUIDs.
OK. The point was: if folks on PCs have a workflow that works for
them, wonderful. That workflow doesn't work so great for me. My
workflow doesn't hurt them. Why is it bad?
This discussion is over, since you're not willing to actually discuss
it (illustrated by you cutting and pasting this same thing four
times in your reply.)
My NAK stands until such time that you can partake in a reasonable
discussion.
The point of pasting it several times was that you'd answer it.
Apparently that failed.
Perhaps you could answer the question I posed?
No, because you haven't taken the time to think and consider my
reply, which gives you insight into how your "problem" is no
different from the situation that everyone else has, where it
isn't a problem.

I think the "problem" here is that you've got used to coreboot
doing something that very few other boot loaders do, namely it
automatically extracting a rootfs UUID for you. The rest of the
world doesn't have that luxury.

So, instead, you want to stuff more code into the kernel to work
around what you think is a problem - a problem which seems to be
unique to yourself.

The UUID and label solutions were created by x86 people to work
around exactly this dynamic device problem, and as my previous
replies have shown, it is superior to fixing the device assignment
as you're trying to do.

However, I don't expect that you'll like this answer, and you'll
probably just re-post your same question after each and every
paragraph rather than considering whether the already existing
solutions could solve your "problem". So I'm just wasting my time.

This is my last reply.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
Doug Anderson
2016-04-29 21:39:35 UTC
Permalink
Russell,

On Fri, Apr 29, 2016 at 2:29 PM, Russell King - ARM Linux
Post by Russell King - ARM Linux
No, because you haven't taken the time to think and consider my
reply, which gives you insight into how your "problem" is no
different from the situation that everyone else has, where it
isn't a problem.
I have certainly considered it.
Post by Russell King - ARM Linux
I think the "problem" here is that you've got used to coreboot
doing something that very few other boot loaders do, namely it
automatically extracting a rootfs UUID for you. The rest of the
world doesn't have that luxury.
Earlier in this thread Rob nicely proposed a solution to my TFTP. I
agreed that was a nice solution. I can certainly use it. Certainly
there are many places where UUIDs are awesome. ...but that's still no
reason to assign a random number when a sane and logical numbering
system exists for MMC parts on a given SoC.
Post by Russell King - ARM Linux
So, instead, you want to stuff more code into the kernel to work
around what you think is a problem - a problem which seems to be
unique to yourself.
Not so much. I think many people have expressed interest in something
like this. It seems unlikely to be unique.
Post by Russell King - ARM Linux
The UUID and label solutions were created by x86 people to work
around exactly this dynamic device problem, and as my previous
replies have shown, it is superior to fixing the device assignment
as you're trying to do.
Sure. They don't have the luxury of having a simple and consistent
numbering so they're forced to use UUIDs for booting and have the
extra mental work of mapping IDs to physical hardware. ...so they're
forced to use UUIDs.
Post by Russell King - ARM Linux
However, I don't expect that you'll like this answer, and you'll
probably just re-post your same question after each and every
paragraph rather than considering whether the already existing
solutions could solve your "problem". So I'm just wasting my time.
Really I just reposted it several times because I notice that you seem
to ignore many points of my emails. I was really hoping to get you to
address this point. I notice that you still didn't. Either you are
just trying to annoy me, or you don't have an answer to how my patch
series hurts you.
Post by Russell King - ARM Linux
This is my last reply.
Excellent. I look forward to your silence.

-Doug
Russell King - ARM Linux
2016-04-29 21:50:17 UTC
Permalink
On Fri, Apr 29, 2016 at 02:39:35PM -0700, Doug Anderson wrote:
[didn't read most of your reply]
Post by Doug Anderson
Really I just reposted it several times because I notice that you seem
to ignore many points of my emails. I was really hoping to get you to
address this point. I notice that you still didn't. Either you are
just trying to annoy me, or you don't have an answer to how my patch
series hurts you.
I don't see you treating Rob with the same contempt that you have
treated me in this thread, despite Rob and myself both telling you
basically the same thing.

Maybe you should try some of the solutions we're suggesting, rather
than hammering away at your keyboard because you disagree with the
feedback that you're getting, to see whether these other solutions
resolve it.

I notice that your replies focuses solely on UUIDs to my messages,
despite *my* messages also talking about labels. Therefore, I think
you are _not_ actually reading my replies - if you were, then you
would have noticed that I've been making the same suggestion as Rob.

Also, the speed at which you hammer out your replies (in as little
as minutes) suggests that you aren't reading them.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
Doug Anderson
2016-04-29 21:56:38 UTC
Permalink
Russell,

On Fri, Apr 29, 2016 at 2:50 PM, Russell King - ARM Linux
Post by Russell King - ARM Linux
[didn't read most of your reply]
Post by Doug Anderson
Really I just reposted it several times because I notice that you seem
to ignore many points of my emails. I was really hoping to get you to
address this point. I notice that you still didn't. Either you are
just trying to annoy me, or you don't have an answer to how my patch
series hurts you.
I don't see you treating Rob with the same contempt that you have
treated me in this thread, despite Rob and myself both telling you
basically the same thing.
Rob wrote a nice thoughtful reply and I tried to give a nice
thoughtful reply back to him. He raised some good points and I raised
some good points back to him. I look forward to his future thoughts
on the topic.


-Doug
Russell King - ARM Linux
2016-04-29 22:16:07 UTC
Permalink
Post by Doug Anderson
Russell,
On Fri, Apr 29, 2016 at 2:50 PM, Russell King - ARM Linux
Post by Russell King - ARM Linux
[didn't read most of your reply]
Post by Doug Anderson
Really I just reposted it several times because I notice that you seem
to ignore many points of my emails. I was really hoping to get you to
address this point. I notice that you still didn't. Either you are
just trying to annoy me, or you don't have an answer to how my patch
series hurts you.
I don't see you treating Rob with the same contempt that you have
treated me in this thread, despite Rob and myself both telling you
basically the same thing.
Rob wrote a nice thoughtful reply and I tried to give a nice
thoughtful reply back to him. He raised some good points and I raised
some good points back to him. I look forward to his future thoughts
on the topic.
Meanwhile, I've pointed out that you appear to be coming from a
misunderstanding (that's certainly clear because you believed
initially that grub did something it doesn't), showing that the
"problem" you have is no different from the majority of other
systems running Linux, and you treat me with contempt.

What are you going to do to resolve this?
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
Doug Anderson
2016-04-29 22:22:50 UTC
Permalink
Hi,

On Fri, Apr 29, 2016 at 3:16 PM, Russell King - ARM Linux
Post by Russell King - ARM Linux
Post by Doug Anderson
Russell,
On Fri, Apr 29, 2016 at 2:50 PM, Russell King - ARM Linux
Post by Russell King - ARM Linux
[didn't read most of your reply]
Post by Doug Anderson
Really I just reposted it several times because I notice that you seem
to ignore many points of my emails. I was really hoping to get you to
address this point. I notice that you still didn't. Either you are
just trying to annoy me, or you don't have an answer to how my patch
series hurts you.
I don't see you treating Rob with the same contempt that you have
treated me in this thread, despite Rob and myself both telling you
basically the same thing.
Rob wrote a nice thoughtful reply and I tried to give a nice
thoughtful reply back to him. He raised some good points and I raised
some good points back to him. I look forward to his future thoughts
on the topic.
Meanwhile, I've pointed out that you appear to be coming from a
misunderstanding (that's certainly clear because you believed
initially that grub did something it doesn't), showing that the
"problem" you have is no different from the majority of other
systems running Linux, and you treat me with contempt.
What are you going to do to resolve this?
As I tried to indicate in earlier emails, I don't actually care how
grub works in this case. It was originally meant to illustrate the
other people's workflows and mine are not the same. If they have a
solution that works for them, that's great.

I want my MMC and MMCBLK device numbers to be sane and consistent to
help me parse through dmesg and sysfs. If it happens to also make it
easy / possible to specify a root filesystem using "mmcblkN" that's
great and I'll probably take advantage of that.

I'm very sorry if those using SATA and ATA disks don't have a way to
get sane and consistent device number ordering. I really am. ...but
just because they don't have a well defined ordering doesn't mean
those of us using MMC should have to suffer. ...and I don't think
giving a sane ordering to MMC devices hurts anyone, does it?

-Doug
Russell King - ARM Linux
2016-04-29 22:44:07 UTC
Permalink
Post by Doug Anderson
Hi,
On Fri, Apr 29, 2016 at 3:16 PM, Russell King - ARM Linux
Post by Russell King - ARM Linux
Post by Doug Anderson
Russell,
On Fri, Apr 29, 2016 at 2:50 PM, Russell King - ARM Linux
Post by Russell King - ARM Linux
[didn't read most of your reply]
Post by Doug Anderson
Really I just reposted it several times because I notice that you seem
to ignore many points of my emails. I was really hoping to get you to
address this point. I notice that you still didn't. Either you are
just trying to annoy me, or you don't have an answer to how my patch
series hurts you.
I don't see you treating Rob with the same contempt that you have
treated me in this thread, despite Rob and myself both telling you
basically the same thing.
Rob wrote a nice thoughtful reply and I tried to give a nice
thoughtful reply back to him. He raised some good points and I raised
some good points back to him. I look forward to his future thoughts
on the topic.
Meanwhile, I've pointed out that you appear to be coming from a
misunderstanding (that's certainly clear because you believed
initially that grub did something it doesn't), showing that the
"problem" you have is no different from the majority of other
systems running Linux, and you treat me with contempt.
What are you going to do to resolve this?
As I tried to indicate in earlier emails, I don't actually care how
grub works in this case. It was originally meant to illustrate the
other people's workflows and mine are not the same. If they have a
solution that works for them, that's great.
... and so far you haven't really showed how your workflow is soo
different from that found on a typical x86 or ARM platform not using
coreboot. Give an example of how your workflow would differ from
using u-boot.
Post by Doug Anderson
I want my MMC and MMCBLK device numbers to be sane and consistent to
help me parse through dmesg and sysfs. If it happens to also make it
easy / possible to specify a root filesystem using "mmcblkN" that's
great and I'll probably take advantage of that.
While I can relate to that as a desire, the idea of having a stable
device namespace is something that has been rejected by kernel
developers over quite a period of time for all sorts of devices.
Post by Doug Anderson
I'm very sorry if those using SATA and ATA disks don't have a way to
get sane and consistent device number ordering. I really am. ...but
just because they don't have a well defined ordering doesn't mean
those of us using MMC should have to suffer. ...and I don't think
giving a sane ordering to MMC devices hurts anyone, does it?
My reply would be... why should MMC have special handling that no
other subsystem has?

Here's another example. Plug in several USB serial adapters. Which
USB serial /dev/ttyUSB* device corresponds to which adapter? The
answer is... it depends on the order you plug them in, which could
well be different from the order in which they are found if the
machine reboots. That's a very real problem.

However, the answer to this problem is not to find some way to bind
a particular /dev/ttyUSB* node to a particular USB device, but to
use the solution(s) already provided - iow, /dev/serial/by-id or
/dev/serial/by-path trees which give a stable view of these devices.

Now, while that allows the appropriate /dev/ttyUSB* device to be
found, it doesn't solve the "which ttyUSB* entry in the kernel
message log corresponds with which adapter" (which is the basis
of your point #1.) That's not solved, and isn't purposely isn't
solved for any kernel subsystem.

Another example - I have boards here with multiple RTCs... guess
what happens with those? Yep, same problem. They get dynamic
/dev/rtc* assignment.

Another example - I have a board with three ethernet devices...
yep, same problem again, the order depends on the driver probe
order, and they get dynamically assigned eth* names.

The list of subsystems that have this property is large, because
it's all dependent on the device/driver probing order.

So, please answer this question: why should _only_ MMC be treated
as a special case? Please give a _technical_ reason rather than a
_personal_ reason.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
Doug Anderson
2016-04-29 23:01:58 UTC
Permalink
Hi,

On Fri, Apr 29, 2016 at 3:44 PM, Russell King - ARM Linux
Post by Russell King - ARM Linux
My reply would be... why should MMC have special handling that no
other subsystem has?
No other subsystem?

* i2c allows numbering devices by alias
* rtc allows numbering devices by alias.
* serial allows numbering devices by alias.
* spi allows numbering devices by alias.
* watchdog allows numbering devices by alias.

...at least that's my impression doing a grep for of_alias_get_id(),
which I suggested earlier in this thread but apparently wasn't done.
Post by Russell King - ARM Linux
Here's another example. Plug in several USB serial adapters. Which
USB serial /dev/ttyUSB* device corresponds to which adapter? The
answer is... it depends on the order you plug them in, which could
well be different from the order in which they are found if the
machine reboots. That's a very real problem.
USB is, by definition, hotplug and probable and there is no ordering.
For peripherals built-in to a SoC there is a sane ordering. Thus
hotplug peripherals and builtin peripherals shouldn't have the same
requirements.

Quite honestly, it _would_ be quite convenient that if you are on a
SoC and you know it has builtin USB controllers to have the root hubs
numbered in a sane and consistent manner. An area for a future patch,
maybe.
Post by Russell King - ARM Linux
However, the answer to this problem is not to find some way to bind
a particular /dev/ttyUSB* node to a particular USB device, but to
use the solution(s) already provided - iow, /dev/serial/by-id or
/dev/serial/by-path trees which give a stable view of these devices.
Now, while that allows the appropriate /dev/ttyUSB* device to be
found, it doesn't solve the "which ttyUSB* entry in the kernel
message log corresponds with which adapter" (which is the basis
of your point #1.) That's not solved, and isn't purposely isn't
solved for any kernel subsystem.
Another example - I have boards here with multiple RTCs... guess
what happens with those? Yep, same problem. They get dynamic
/dev/rtc* assignment.
Are you quite certain about that? See above.
Post by Russell King - ARM Linux
Another example - I have a board with three ethernet devices...
yep, same problem again, the order depends on the driver probe
order, and they get dynamically assigned eth* names.
Ethernet is often provided by USB and thus hotplug and probable.
Quite honestly if there was a builtin Ethernet adapter provided on a
SoC (not connected over USB), it would be super handy if it was forced
to be "eth0" (and if there were more than one if they could be ordered
in a way that made sense for that SoC). Dynamic ordering could come
after.
Post by Russell King - ARM Linux
The list of subsystems that have this property is large, because
it's all dependent on the device/driver probing order.
Sure. For hotplug, there is no sane device ordering.

For things built in to an SoC, there is sane device ordering. Dynamic
ordering should come after static.
Post by Russell King - ARM Linux
So, please answer this question: why should _only_ MMC be treated
as a special case? Please give a _technical_ reason rather than a
_personal_ reason.
Because technically it makes it easier for people to understand their
system to have a sane ordering for builtin peripherals.


-Doug
Peter Hurley
2016-04-29 23:58:12 UTC
Permalink
Post by Doug Anderson
* serial allows numbering devices by alias.
Which is in fact a total nightmare.

While stable device order is mandatory in serial because of
console command line parameters and existing userspace expectations,
it is the number one barrier to providing a shared ttyS namespace
for mixed uart platforms.

Stable device order has a very real (and often unforeseen) maintenance
burden.

For example, I noticed these patches are strictly for DT.
I'm assuming that's because guaranteeing stable device order for
mmc in general is more difficult; eg., by performing minimal scan
serially and more expensive portion of the probe async.

Regards,
Peter Hurley
Peter Hurley
2016-04-30 00:31:31 UTC
Permalink
Post by Peter Hurley
Hi,
Post by Doug Anderson
* serial allows numbering devices by alias.
Which is in fact a total nightmare.
While stable device order is mandatory in serial because of
console command line parameters and existing userspace expectations,
it is the number one barrier to providing a shared ttyS namespace
for mixed uart platforms.
Stable device order has a very real (and often unforeseen) maintenance
burden.
Interesting. I wonder if these burdens are unique to serial or shared
by all the other subsystems that allow ordering? Maybe this is all
because of legacy reasons?
Well, the specific issue is certainly unique to serial.
But what I was suggesting is that 5 years from now, these patches
could be the "legacy reasons" in mmc.

FWIW, there is already a defacto expectation by boot configurations in the
field that a given mmc block device is stable across boots. The reality
is that 100000's of kernel command lines look like:

root=/dev/mmcblk0p2

This was a recent regression fixed by Ulf in commit 9aaf3437aa72
("mmc: block: Use the mmc host device index as the mmcblk device index")
Post by Peter Hurley
Note that for MMC devices we wouldn't be asserting that _every_
device has a stable order. Only those known at boot.
For example, I noticed these patches are strictly for DT.
I'm assuming that's because guaranteeing stable device order for
mmc in general is more difficult; eg., by performing minimal scan
serially and more expensive portion of the probe async.
Presumably if there were another system similar to DT where we knew
all the possible built-in devices right at boot then we could
extend.
...but yes, obviously this wouldn't be a sane thing to do for
anything probable like PCI or USB.
SCSI does. Here's what Linus said:

"So the *simple* model is to just scan the devices minimally serially,
and allocate the names at that point (so the names are reliable
between boots for the same hardware configuration). And then do the
more expensive device setup asynchronously (ie querying device
information, spinning up disks, whatever - things that can take
anything from milliseonds to several seconds, because they are doing
actual IO). So you'd do some very basic (and _often_ fairly quick)
operations serially, but then try to do the expensive parts
concurrently.

The SCSI layer actually goes a bit further than that: it has a fairly
asynchronous scanning thing, but it does allocate the actual host
device nodes serially, and then it even has an ordered list of
"scanning_hosts" that is used to complete the scanning in-order, so
that the sysfs devices show up in the right order even if things
actually got scanned out-of-order. So scans that finished early will
wait for other scans that are for "earlier" devices, and you end up
with what *looks* ordered to the outside, even if internally it was
all done out-of-order.
"

Regards,
Peter Hurley
Doug Anderson
2016-04-30 02:29:22 UTC
Permalink
Hi,
Post by Peter Hurley
Post by Peter Hurley
Hi,
Post by Doug Anderson
* serial allows numbering devices by alias.
Which is in fact a total nightmare.
While stable device order is mandatory in serial because of
console command line parameters and existing userspace expectations,
it is the number one barrier to providing a shared ttyS namespace
for mixed uart platforms.
Stable device order has a very real (and often unforeseen) maintenance
burden.
Interesting. I wonder if these burdens are unique to serial or shared
by all the other subsystems that allow ordering? Maybe this is all
because of legacy reasons?
Well, the specific issue is certainly unique to serial.
But what I was suggesting is that 5 years from now, these patches
could be the "legacy reasons" in mmc.
FWIW, there is already a defacto expectation by boot configurations in the
field that a given mmc block device is stable across boots. The reality
root=/dev/mmcblk0p2
This was a recent regression fixed by Ulf in commit 9aaf3437aa72
("mmc: block: Use the mmc host device index as the mmcblk device index")
Ah. Well, in this case it sounds like we've already got an
expectation of stable numbering from boot to boot. I had missed Ulf's
patch, so I guess part 3 of my series isn't actually needed and can be
dropped.

So it's just a question of whether we allow people to manually specify
via device tree.


Note: if we really think using root=/dev/mmcblkNpM is a bad idea then
we should deprecate it and yell about it in the boot log. Then 5 (or
20) years down the road we could remove the feature when the legacy
burden become a pain. Note that even if we deprecated
root=/dev/mmcblkNpM I'd still love to see the numbering be consistent
to help folks parse dmesg.


Thanks for your thoughts!


-Doug
Russell King - ARM Linux
2016-04-30 08:38:16 UTC
Permalink
Post by Peter Hurley
FWIW, there is already a defacto expectation by boot configurations in the
field that a given mmc block device is stable across boots. The reality
root=/dev/mmcblk0p2
Thankfully, MMC does generally give a stable naming across reboots -
I have platforms with eMMC and SD (eg, the SDP4430 board which is in
the test farm) and only when things change in the kernel does the
MMC device name change.

Changes in device ordering can be provoked by the order in which
entries in the DT file appear, and hence the order in which the host
SD interfaces are probed by the kernel.

When it changed, I switched from using the device specifier to using
a UUID. Now I have no problems since I no longer care which MMC
block device ends up as the SD card.

The kernel there is TFTP'd too.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
Rob Herring
2016-04-30 13:23:17 UTC
Permalink
Post by Doug Anderson
Hi,
On Fri, Apr 29, 2016 at 3:44 PM, Russell King - ARM Linux
Post by Russell King - ARM Linux
My reply would be... why should MMC have special handling that no
other subsystem has?
No other subsystem?
* i2c allows numbering devices by alias
* rtc allows numbering devices by alias.
* serial allows numbering devices by alias.
* spi allows numbering devices by alias.
* watchdog allows numbering devices by alias.
...at least that's my impression doing a grep for of_alias_get_id(),
which I suggested earlier in this thread but apparently wasn't done.
IMO, we should remove most or all of these not add more. We shoud move
to identifying devices by other OS independent means. Peter already
pointed out why serial is a problem.

Rob
Javier Martinez Canillas
2016-04-29 22:42:35 UTC
Permalink
Hello Russell,

On Fri, Apr 29, 2016 at 6:16 PM, Russell King - ARM Linux
Post by Russell King - ARM Linux
Post by Doug Anderson
Russell,
On Fri, Apr 29, 2016 at 2:50 PM, Russell King - ARM Linux
Post by Russell King - ARM Linux
[didn't read most of your reply]
Post by Doug Anderson
Really I just reposted it several times because I notice that you seem
to ignore many points of my emails. I was really hoping to get you to
address this point. I notice that you still didn't. Either you are
just trying to annoy me, or you don't have an answer to how my patch
series hurts you.
I don't see you treating Rob with the same contempt that you have
treated me in this thread, despite Rob and myself both telling you
basically the same thing.
Rob wrote a nice thoughtful reply and I tried to give a nice
thoughtful reply back to him. He raised some good points and I raised
some good points back to him. I look forward to his future thoughts
on the topic.
Meanwhile, I've pointed out that you appear to be coming from a
misunderstanding (that's certainly clear because you believed
initially that grub did something it doesn't), showing that the
"problem" you have is no different from the majority of other
systems running Linux, and you treat me with contempt.
What are you going to do to resolve this?
Maybe a third opinion could make this conversation constructive again.

I think Doug's point is that using a UUID or labels for consistency is
orthogonal to having a deterministic numbering for MMC devices. And I
agree with his point of view for what is worth.

I understand that this not true for other systems and peripherals but
in the specific case of MMC, the changes are minimal as Doug's patches
have shown and even the technical manual of SoCs has an enumeration to
refer each SD/MMC slot.

So I think is fair to say that SD/MMC is different than say USB mass
storage devices as you mentioned, and having a consistent numbering is
very helpful for diagnostics and debugging purposes IMHO.

BTW, I use labels in all my systems because as you said it's nice to
be able to swap cards and not change the bootloader env vars, but I
see how having a deterministic numbering could be useful to others.

Best regards,
Javier
Russell King - ARM Linux
2016-04-30 10:48:33 UTC
Permalink
Post by Javier Martinez Canillas
Maybe a third opinion could make this conversation constructive again.
I think Doug's point is that using a UUID or labels for consistency is
orthogonal to having a deterministic numbering for MMC devices. And I
agree with his point of view for what is worth.
Yes, it may be orthogonal, but there are two issues here:

1. How does the system know which MMC device to mount for its rootfs.

This is the point that I've picked up on, which has been solved for
years, and actually pre-dates MMC support in the kernel, and that is
mount by UUID.

The kernel itself has no support for mount-by-label, which is normally
solved by using an initramfs, which contains programs such as mount
etc which will scan the block devices looking for an appropriately
labelled filesystem. Label has slightly more issues since its possible
that you could end up with two filesystems with the same label (eg, on
x86, you're migrating your disks, and you plug in a disk which has a
label of "/" but is not your intended rootfs.)

Of course, any scheme which relies on an identifier on the disk may
result in some kind of clash if another partition/disk has the same
identifier.

2. The identifier found in kernel messages for each MMC device.

This is where Doug and myself disagree. I don't see this as a big
problem - the big problem is (1) above, which is the one which can
lead to a non-functional system. I believe that the actual name
that we end up with is a cosmetic issue.

What I've been trying to point out is that the same cosmetic issue
occurs elsewhere in the kernel, particularly with disks on SATA
interfaces. I've lost count of the number of times that my IDE
disks on one of my machines have changed between /dev/hda, /dev/hdc,
/dev/sda, /dev/sdc, etc. Thankfully, these are part of a raid
array, and they are always constructed to appear as /dev/md* devices
which are the devices that are mounted.

The device names that they end up with depend on which drivers are
built-in to the kernel, and the order in which the device drivers
and devices are probed. There's no way to tell the kernel "I want
PCI card X socket Y to be _this_ device name" and that's a concious
decision that was made years ago.

However, it's a cosmetic issue - reading the log reveals which is
which, and MMC is no different - the information required is in the
log.

Here's some material on the problem:

http://www.tldp.org/HOWTO/Partition/devices.html
http://tldp.org/HOWTO/Partition-Mass-Storage-Definitions-Naming-HOWTO/x99.html
https://lkml.org/lkml/1997/5/4/54
http://marc.info/?l=linux-raid&m=113595057816321&w=2

The first two show that it's well understood (and documented) that
storage devices are dynamically assigned and variable.

The third is an example of how old this problem is - almost twenty
years old, and it hasn't been "solved" on x86 except by using UUID/
labels.

The forth is an example of the "problem" that this dynamic device
assignment causes, and again shows that kernel folk have chosen
not to solve it by way of the problem still existing today.

I guess I don't see it as much of problem because I've been doing
this for over a decade.

Now, thinking outside the box - if it's desirable for eMMC to be
treated differently from regular MMC slots, maybe the solution to
this problem is to have eMMC occupy a separate namespace, rather
than using the /dev/mmcblk* namespace. IOW, /dev/emmc* ?

The /dev/mmcblk* namespace was designed (by me) to be dynamic,
because MMC (not SD) bus structure allows for multiple cards on the
same MMC host interface, much like a SCSI bus allows for multiple
devices on the same cable. Hence, tying individual mmcblkN to
the mmcN host interface is wrong.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
Trent Piepho
2016-05-03 19:17:34 UTC
Permalink
Post by Russell King - ARM Linux
Post by Javier Martinez Canillas
Maybe a third opinion could make this conversation constructive again.
And maybe a forth.
Post by Russell King - ARM Linux
Post by Javier Martinez Canillas
I think Doug's point is that using a UUID or labels for consistency is
orthogonal to having a deterministic numbering for MMC devices. And I
agree with his point of view for what is worth.
1. How does the system know which MMC device to mount for its rootfs.
This is the point that I've picked up on, which has been solved for
years, and actually pre-dates MMC support in the kernel, and that is
mount by UUID.
What about eMMC boot blocks and replay protected memory block? These
are special sub-device like features of eMMC that provide storage from
different areas than the normal flash. The kernel names them something
like "/dev/mmcblk0boot0" and "/dev/mmcblk1rpmb".

They typically don't have partition tables and in fact the kernel
xplicitly does not scan them for a partition table. So how can they
have a UUID?

Suppose your device has two SD slots, neither with an SD card inserted
in it, one external and one internal behind a locked access panel. They
serve different purposes. How do you determine which is which via UUID
when they have no media?
Post by Russell King - ARM Linux
The kernel itself has no support for mount-by-label, which is normally
solved by using an initramfs, which contains programs such as mount
etc which will scan the block devices looking for an appropriately
labelled filesystem. Label has slightly more issues since its possible
But what is faster, using an initramfs that loads a working userspace
into RAM, scans the flash device for partition labels, determines the
device ID, and then switches to the real rootfs. Or having the
bootloader, which already knows the partition the rootfs is in, tell the
kernel what device to mount from the beginning?

Which brings me to another reason for providing device enumeration
information via the device tree that isn't just about mounting the root
filesystem.

The bootloader will create an enumeration of devices so that it can
access them. The kernel will also create an enumeration of the same
devices. Should these enumerations be the same, or should they be
different?

Clearly there are advantages to the enumeration being the same. It's
easier on users if device IDs can be the same between the two
environments, bootloader and kernel, the device can be accessed from.

It also makes it easier if information about a device needs to be passed
from the bootloader to the kernel. This could be the root filesystem,
but that's not the only thing. Console serial port is another. But we
could also want to kernel to know which of the SoC's ports is connected
to the blank eMMC chip it should create a partition table on and format,
and which is connected to the SD card it should store logging data to.

I can't think of any advantage of the enumerations being different.

So if identical enumerations are desirable, how to achieve it?

One way would be to have the bootloader create its enumeration and then
throw it away when the kernel boots. The the kernel creates a new
enumeration from scratch, using a different system with different code
and a different design, that happens to create the same enumeration that
the bootloader did. This seems like a bad design to me. Two different
code bases will need to kept in sync, to always to the same thing in a
different way. It will be hard to avoid bugs from corner cases that
fail to produce the same enumerations.

Another way would be to have the bootloader tell the kernel what it
enumerated and then have the kernel use this enumeration. This avoids
the need to keep two code bases in sync. It avoids bugs where they fail
to produce the same enumeration.

And how to do this pass the enumeration from the bootloader to the
kernel? The same way all other information from the bootloader is
passed to the kernel, via the device tree.

The alias system that already exists allows the bootloader to tell the
kernel about enumerations it has already created, which it must do since
it runs before the kernel, and would like the kernel to continue to use.

So this isn't just about finding the root filesystem. It's about
passing enumeration information from the bootloader to the kernel.
Pavel Machek
2016-05-04 07:18:01 UTC
Permalink
Post by Russell King - ARM Linux
Post by Douglas Anderson
This series picks patches from various different places to produce what
I consider the best solution to getting consistent mmc and mmcblk
ordering.
Why consistent ordering and why not just use UUIDs? IMHO consistent
NAK. Really. Use UUIDs, that's the proper solution here.
Except that UUIDs do not solve the problem.

You have just booted of nfsroot, and you want to format u-SD card in
the external slot. How do you do that?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Rob Herring
2016-05-04 12:25:42 UTC
Permalink
Post by Pavel Machek
Post by Russell King - ARM Linux
Post by Douglas Anderson
This series picks patches from various different places to produce what
I consider the best solution to getting consistent mmc and mmcblk
ordering.
Why consistent ordering and why not just use UUIDs? IMHO consistent
NAK. Really. Use UUIDs, that's the proper solution here.
Except that UUIDs do not solve the problem.
You have just booted of nfsroot, and you want to format u-SD card in
the external slot. How do you do that?
The same way you format a USB stick when you insert it.

If you have built-in versus removable, then we should expose that
information to userspace rather than some arbitrary encoding in DT
that 0 means built-in and 1 means removable. Or if you have multiple
slots, then use "label" to provide meaningful slot names.

Rob
Pavel Machek
2016-05-04 12:46:53 UTC
Permalink
Post by Rob Herring
Post by Pavel Machek
Post by Russell King - ARM Linux
Post by Douglas Anderson
This series picks patches from various different places to produce what
I consider the best solution to getting consistent mmc and mmcblk
ordering.
Why consistent ordering and why not just use UUIDs? IMHO consistent
NAK. Really. Use UUIDs, that's the proper solution here.
Except that UUIDs do not solve the problem.
You have just booted of nfsroot, and you want to format u-SD card in
the external slot. How do you do that?
The same way you format a USB stick when you insert it.
Well, and that actually brings related question "how do you format the
right USB stick if you have 5 of them connected". PCs don't have good
solution, but that does not mean it can't be solved.

And no, its not really the same. At least in N900 case, I'm not really
sure if you are expected to manipulate the u-SD card while the system
is on. It is under battery cover.
Post by Rob Herring
If you have built-in versus removable, then we should expose that
information to userspace rather than some arbitrary encoding in DT
that 0 means built-in and 1 means removable. Or if you have multiple
slots, then use "label" to provide meaningful slot names.
Yes, labels would be nice. Plus the slot numbers should be stable, so
that booting does not randomly break.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Continue reading on narkive:
Loading...