adding aliases to mmc ... again

adding aliases to mmc ... again

[Sascha Hauer]

Hi all,

The wish to have persistent MMC block device names for passing a suitable
root=/dev/mmcblkX option came up several times already and has been discussed
at least in these threads:

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/109984.html
https://www.mail-archive.com/linux-mmc@vger.kernel.org/msg22104.html
http://comments.gmane.org/gmane.linux.kernel.mmc/21519

Several patches have been proposed to nail the slot index to a known number.
Arguments against these patches were:

- Use an initrd and locate the correct root device there
  even Thomas who suggested this admitted this would be painful to do
- use root=UUID= or root=PARTUUID=
  This generally works but has an important downside. With the UUID
  approach devices which should boot from the internal eMMC may start
  booting from an external SD slot when somebody deliberately inserts
  a SD card with the same UUID.

The following patches should have the technical issues fixed. It works
by counting the mmc aliases in the devicetree during initialization of
the mmc framework. Those slot numbers will never be assigned to other
hosts.

Sascha

----------------------------------------------------------------
Sascha Hauer (2):
      of: Add helper for getting the maximum alias index for a stem
      mmc: Allow setting slot index via devicetree alias

 drivers/mmc/card/block.c | 11 ++++++++++-
 drivers/mmc/core/core.c  | 37 +++++++++++++++++++++++++++++++++++++
 drivers/mmc/core/host.c  | 17 +++++++++++++++--
 drivers/of/base.c        | 29 +++++++++++++++++++++++++++++
 include/linux/mmc/core.h |  3 +++
 include/linux/of.h       |  6 ++++++
 6 files changed, 100 insertions(+), 3 deletions(-)

[PATCH 1/2] of: Add helper for getting the maximum alias index for a stem

[Sascha Hauer]

of_alias_max_index will return the maximum number for which an
alias of a given stem exists. This is useful for frameworks
whishing to reserve a number of device slots from dynamic
allocation.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 drivers/of/base.c  | 29 +++++++++++++++++++++++++++++
 include/linux/of.h |  6 ++++++
 2 files changed, 35 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index f807d0e..f953b9d 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1758,6 +1758,35 @@ static void of_alias_add(struct alias_prop *ap, struct device_node *np,
 		 ap->alias, ap->stem, ap->id, of_node_full_name(np));
 }
 
+/*
+ * of_alias_max_index() - get the maximum index for a given alias stem
+ * @stem:   The alias stem for which the maximum index is searched for
+ *
+ * Given an alias stem (the alias without the number) this function
+ * returns the maximum number for which an alias exists.
+ *
+ * Return: The maximum existing alias index or -ENODEV if no alias
+ *         exists for this stem.
+ */
+int of_alias_max_index(const char *stem)
+{
+	struct alias_prop *app;
+	int max = -ENODEV;
+
+	mutex_lock(&of_aliases_mutex);
+
+	list_for_each_entry(app, &aliases_lookup, link) {
+		if (strcmp(app->stem, stem))
+			continue;
+		if (app->id > max)
+			max = app->id;
+	}
+
+	mutex_unlock(&of_aliases_mutex);
+
+	return max;
+}
+
 /**
  * of_alias_scan - Scan all properties of 'aliases' node
  *
diff --git a/include/linux/of.h b/include/linux/of.h
index 276c546..963e295 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -305,6 +305,7 @@ extern int of_count_phandle_with_args(const struct device_node *np,
 
 extern void of_alias_scan(void * (*dt_alloc)(u64 size, u64 align));
 extern int of_alias_get_id(struct device_node *np, const char *stem);
+extern int of_alias_max_index(const char *stem);
 
 extern int of_machine_is_compatible(const char *compat);
 
@@ -532,6 +533,11 @@ static inline int of_alias_get_id(struct device_node *np, const char *stem)
 	return -ENOSYS;
 }
 
+static inline int of_alias_max_index(const char *stem)
+{
+	return -ENODEV;
+}
+
 static inline int of_machine_is_compatible(const char *compat)
 {
 	return 0;
-- 
2.0.0.rc0

[PATCH 2/2] mmc: Allow setting slot index via devicetree alias

[Sascha Hauer]

As with gpio, uart and others, allow specifying the name_idx via the
aliases-node in the devicetree.

On embedded devices, there is often a combination of removable (e.g.
SD card) and non-removable mmc devices (e.g. eMMC).
Therefore the name_idx might change depending on
        - host of removable device
        - removable card present or not

This makes it difficult to hard code the root device, if it is on the
non-removable device. E.g. if SD card is present eMMC will be mmcblk1,
if SD card is not present at boot, eMMC will be mmcblk0.

If the aliases-node is not found, the driver will act as before.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 drivers/mmc/card/block.c | 11 ++++++++++-
 drivers/mmc/core/core.c  | 37 +++++++++++++++++++++++++++++++++++++
 drivers/mmc/core/host.c  | 17 +++++++++++++++--
 include/linux/mmc/core.h |  3 +++
 4 files changed, 65 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 29d5d98..9735252 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -32,6 +32,7 @@
 #include <linux/scatterlist.h>
 #include <linux/string_helpers.h>
 #include <linux/delay.h>
+#include <linux/of.h>
 #include <linux/capability.h>
 #include <linux/compat.h>
 #include <linux/pm_runtime.h>
@@ -2044,7 +2045,15 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card,
 	 * index anymore so we keep track of a name index.
 	 */
 	if (!subname) {
-		md->name_idx = find_first_zero_bit(name_use, max_devices);
+		int idx;
+
+		idx = mmc_get_reserved_index(card->host);
+		if (idx >= 0 && !test_bit(idx, name_use))
+			md->name_idx = idx;
+		else
+			md->name_idx = find_next_zero_bit(name_use, max_devices,
+					mmc_first_nonreserved_index());
+
 		__set_bit(md->name_idx, name_use);
 	} else
 		md->name_idx = ((struct mmc_blk_data *)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 57a2b40..c959d41 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2711,6 +2711,41 @@ void mmc_init_context_info(struct mmc_host *host)
 	init_waitqueue_head(&host->context_info.wait);
 }
 
+static int __mmc_max_reserved_idx = -1;
+
+/**
+ * mmc_first_nonreserved_index() - get the first index that is not reserved
+ */
+int mmc_first_nonreserved_index(void)
+{
+	return __mmc_max_reserved_idx + 1;
+}
+
+/**
+ * mmc_get_reserved_index() - get the index reserved for this host
+ *
+ * Return: The index reserved for this host or negative error value if
+ *         no index is reserved for this host
+ */
+int mmc_get_reserved_index(struct mmc_host *host)
+{
+	return of_alias_get_id(host->parent->of_node, "mmc");
+}
+
+static void mmc_of_reserve_idx(void)
+{
+	int max;
+
+	max = of_alias_max_index("mmc");
+	if (max < 0)
+		return;
+
+	__mmc_max_reserved_idx = max;
+
+	pr_debug("MMC: reserving %d slots for of aliases\n",
+			__mmc_max_reserved_idx + 1);
+}
+
 static int __init mmc_init(void)
 {
 	int ret;
@@ -2719,6 +2754,8 @@ static int __init mmc_init(void)
 	if (!workqueue)
 		return -ENOMEM;
 
+	mmc_of_reserve_idx();
+
 	ret = mmc_register_bus();
 	if (ret)
 		goto destroy_workqueue;
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 49bc403..ef1e0a8 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -439,6 +439,8 @@ out:
 
 EXPORT_SYMBOL(mmc_of_parse);
 
+int mmc_max_reserved_idx(void);
+
 /**
  *	mmc_alloc_host - initialise the per-host structure.
  *	@extra: sizeof private data structure
@@ -450,6 +452,7 @@ struct mmc_host *mmc_alloc_host(int extra, struct device *dev)
 {
 	int err;
 	struct mmc_host *host;
+	int alias_id, min_idx, max_idx;
 
 	host = kzalloc(sizeof(struct mmc_host) + extra, GFP_KERNEL);
 	if (!host)
@@ -459,7 +462,18 @@ struct mmc_host *mmc_alloc_host(int extra, struct device *dev)
 	host->rescan_disable = 1;
 	idr_preload(GFP_KERNEL);
 	spin_lock(&mmc_host_lock);
-	err = idr_alloc(&mmc_host_idr, host, 0, 0, GFP_NOWAIT);
+
+	host->parent = dev;
+	alias_id = mmc_get_reserved_index(host);
+	if (alias_id >= 0) {
+		min_idx = alias_id;
+		max_idx = alias_id;
+	} else {
+		min_idx = mmc_first_nonreserved_index();
+		max_idx = 0;
+	}
+
+	err = idr_alloc(&mmc_host_idr, host, min_idx, max_idx, GFP_NOWAIT);
 	if (err >= 0)
 		host->index = err;
 	spin_unlock(&mmc_host_lock);
@@ -469,7 +483,6 @@ struct mmc_host *mmc_alloc_host(int extra, struct device *dev)
 
 	dev_set_name(&host->class_dev, "mmc%d", host->index);
 
-	host->parent = dev;
 	host->class_dev.parent = dev;
 	host->class_dev.class = &mmc_host_class;
 	device_initialize(&host->class_dev);
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index 87079fc..96fb4f2 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -197,6 +197,9 @@ extern int mmc_flush_cache(struct mmc_card *);
 
 extern int mmc_detect_card_removed(struct mmc_host *host);
 
+int mmc_first_nonreserved_index(void);
+int mmc_get_reserved_index(struct mmc_host *host);
+
 /**
  *	mmc_claim_host - exclusively claim a host
  *	@host: mmc host to claim
-- 
2.0.0.rc0

Re: adding aliases to mmc ... again

[Stephen Warren]

On 05/22/2014 09:30 AM, Sascha Hauer wrote:
> Hi all,
> 
> The wish to have persistent MMC block device names for passing a suitable
> root=/dev/mmcblkX option came up several times already and has been discussed
> at least in these threads:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/109984.html
> https://www.mail-archive.com/linux-mmc@vger.kernel.org/msg22104.html
> http://comments.gmane.org/gmane.linux.kernel.mmc/21519
> 
> Several patches have been proposed to nail the slot index to a known number.
> Arguments against these patches were:
> 
> - Use an initrd and locate the correct root device there
>   even Thomas who suggested this admitted this would be painful to do
> - use root=UUID= or root=PARTUUID=
>   This generally works but has an important downside. With the UUID
>   approach devices which should boot from the internal eMMC may start
>   booting from an external SD slot when somebody deliberately inserts
>   a SD card with the same UUID.
> 
> The following patches should have the technical issues fixed. It works
> by counting the mmc aliases in the devicetree during initialization of
> the mmc framework. Those slot numbers will never be assigned to other
> hosts.

Does it solve the following, which AFAIK has always been the primary
argument against aligning block device IDs with controller IDs:

- User inserts SD card into MMC controller ID (or alias) 1.
- /dev/mmcblk1 now exists
- Mount /dev/mmcblk1 on /mnt/tmp
- User removes that SD card
- /dev/mmcblk1 still exists, since it's mounted so can't be deleted
after the card removal.
- User inserts SD card into MMC controller ID (or alias) 1.
- /dev/mmcblkN (N is something other than 1) now exists

Now, the block device ID must be != the original ID, since two block
devices exist.

Re: adding aliases to mmc ... again

[Sascha Hauer]

On Thu, May 22, 2014 at 10:16:35AM -0600, Stephen Warren wrote:
> On 05/22/2014 09:30 AM, Sascha Hauer wrote:
> > Hi all,
> > 
> > The wish to have persistent MMC block device names for passing a suitable
> > root=/dev/mmcblkX option came up several times already and has been discussed
> > at least in these threads:
> > 
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/109984.html
> > https://www.mail-archive.com/linux-mmc@vger.kernel.org/msg22104.html
> > http://comments.gmane.org/gmane.linux.kernel.mmc/21519
> > 
> > Several patches have been proposed to nail the slot index to a known number.
> > Arguments against these patches were:
> > 
> > - Use an initrd and locate the correct root device there
> >   even Thomas who suggested this admitted this would be painful to do
> > - use root=UUID= or root=PARTUUID=
> >   This generally works but has an important downside. With the UUID
> >   approach devices which should boot from the internal eMMC may start
> >   booting from an external SD slot when somebody deliberately inserts
> >   a SD card with the same UUID.
> > 
> > The following patches should have the technical issues fixed. It works
> > by counting the mmc aliases in the devicetree during initialization of
> > the mmc framework. Those slot numbers will never be assigned to other
> > hosts.
> 
> Does it solve the following, which AFAIK has always been the primary
> argument against aligning block device IDs with controller IDs:
> 
> - User inserts SD card into MMC controller ID (or alias) 1.
> - /dev/mmcblk1 now exists
> - Mount /dev/mmcblk1 on /mnt/tmp
> - User removes that SD card
> - /dev/mmcblk1 still exists, since it's mounted so can't be deleted
> after the card removal.
> - User inserts SD card into MMC controller ID (or alias) 1.
> - /dev/mmcblkN (N is something other than 1) now exists
> 
> Now, the block device ID must be != the original ID, since two block
> devices exist.

No, it shouldn't solve that, but it's out of scope for this patch. All
it solves is to reliably find the rootfs. If the card containing your
rootfs is removed you are in trouble anyway and it won't help if it gets
the same mmcblkno once it's plugged again. For other devices which don't
contain the rootfs there are enough possibilities to find them in userspace.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: adding aliases to mmc ... again

[Stephen Warren]

On 05/22/2014 12:21 PM, Sascha Hauer wrote:
> On Thu, May 22, 2014 at 10:16:35AM -0600, Stephen Warren wrote:
>> On 05/22/2014 09:30 AM, Sascha Hauer wrote:
>>> Hi all,
>>>
>>> The wish to have persistent MMC block device names for passing a suitable
>>> root=/dev/mmcblkX option came up several times already and has been discussed
>>> at least in these threads:
>>>
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/109984.html
>>> https://www.mail-archive.com/linux-mmc@vger.kernel.org/msg22104.html
>>> http://comments.gmane.org/gmane.linux.kernel.mmc/21519
>>>
>>> Several patches have been proposed to nail the slot index to a known number.
>>> Arguments against these patches were:
>>>
>>> - Use an initrd and locate the correct root device there
>>>   even Thomas who suggested this admitted this would be painful to do
>>> - use root=UUID= or root=PARTUUID=
>>>   This generally works but has an important downside. With the UUID
>>>   approach devices which should boot from the internal eMMC may start
>>>   booting from an external SD slot when somebody deliberately inserts
>>>   a SD card with the same UUID.
>>>
>>> The following patches should have the technical issues fixed. It works
>>> by counting the mmc aliases in the devicetree during initialization of
>>> the mmc framework. Those slot numbers will never be assigned to other
>>> hosts.
>>
>> Does it solve the following, which AFAIK has always been the primary
>> argument against aligning block device IDs with controller IDs:
>>
>> - User inserts SD card into MMC controller ID (or alias) 1.
>> - /dev/mmcblk1 now exists
>> - Mount /dev/mmcblk1 on /mnt/tmp
>> - User removes that SD card
>> - /dev/mmcblk1 still exists, since it's mounted so can't be deleted
>> after the card removal.
>> - User inserts SD card into MMC controller ID (or alias) 1.
>> - /dev/mmcblkN (N is something other than 1) now exists
>>
>> Now, the block device ID must be != the original ID, since two block
>> devices exist.
> 
> No, it shouldn't solve that, but it's out of scope for this patch. All
> it solves is to reliably find the rootfs. If the card containing your
> rootfs is removed you are in trouble anyway and it won't help if it gets
> the same mmcblkno once it's plugged again. For other devices which don't
> contain the rootfs there are enough possibilities to find them in userspace.

I don't think there should be any special cases for the root fs.

I don't think the disadvantage of the UUID= or PARTUUID= issue you
mention enough is really an issue in general. If it is for some
platform, then the root fs should be cryto-signed and validated to
prevent someone from using the wrong root fs.

Re: adding aliases to mmc ... again

[Michael Olbrich]

On Thu, May 22, 2014 at 01:23:27PM -0600, Stephen Warren wrote:
> On 05/22/2014 12:21 PM, Sascha Hauer wrote:
> > On Thu, May 22, 2014 at 10:16:35AM -0600, Stephen Warren wrote:
> >> On 05/22/2014 09:30 AM, Sascha Hauer wrote:
> >>> Hi all,
> >>>
> >>> The wish to have persistent MMC block device names for passing a suitable
> >>> root=/dev/mmcblkX option came up several times already and has been discussed
> >>> at least in these threads:
> >>>
> >>> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/109984.html
> >>> https://www.mail-archive.com/linux-mmc@vger.kernel.org/msg22104.html
> >>> http://comments.gmane.org/gmane.linux.kernel.mmc/21519
> >>>
> >>> Several patches have been proposed to nail the slot index to a known number.
> >>> Arguments against these patches were:
> >>>
> >>> - Use an initrd and locate the correct root device there
> >>>   even Thomas who suggested this admitted this would be painful to do
> >>> - use root=UUID= or root=PARTUUID=
> >>>   This generally works but has an important downside. With the UUID
> >>>   approach devices which should boot from the internal eMMC may start
> >>>   booting from an external SD slot when somebody deliberately inserts
> >>>   a SD card with the same UUID.
> >>>
> >>> The following patches should have the technical issues fixed. It works
> >>> by counting the mmc aliases in the devicetree during initialization of
> >>> the mmc framework. Those slot numbers will never be assigned to other
> >>> hosts.
> >>
> >> Does it solve the following, which AFAIK has always been the primary
> >> argument against aligning block device IDs with controller IDs:
> >>
> >> - User inserts SD card into MMC controller ID (or alias) 1.
> >> - /dev/mmcblk1 now exists
> >> - Mount /dev/mmcblk1 on /mnt/tmp
> >> - User removes that SD card
> >> - /dev/mmcblk1 still exists, since it's mounted so can't be deleted
> >> after the card removal.
> >> - User inserts SD card into MMC controller ID (or alias) 1.
> >> - /dev/mmcblkN (N is something other than 1) now exists
> >>
> >> Now, the block device ID must be != the original ID, since two block
> >> devices exist.

We could limit this to non-removable devices. This problem cannot occur
there. Would that be acceptable?

> > No, it shouldn't solve that, but it's out of scope for this patch. All
> > it solves is to reliably find the rootfs. If the card containing your
> > rootfs is removed you are in trouble anyway and it won't help if it gets
> > the same mmcblkno once it's plugged again. For other devices which don't
> > contain the rootfs there are enough possibilities to find them in userspace.
> 
> I don't think there should be any special cases for the root fs.
> 
> I don't think the disadvantage of the UUID= or PARTUUID= issue you
> mention enough is really an issue in general. If it is for some
> platform, then the root fs should be cryto-signed and validated to
> prevent someone from using the wrong root fs.

To put this in context with a real use-case: what we is "boot from eMMC"
what you're suggesting gives us "don't boot from SD-Card" that's not the
same thing and certainly not an acceptable alternative.

And I find it rather ironic that you suggest a solution that has basically
the problem why you're rejecting the alias solution: In both cases mounting
or using the filesystem we want may fail.

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: adding aliases to mmc ... again

[Stephen Warren]

On 05/23/2014 02:29 AM, Michael Olbrich wrote:
> On Thu, May 22, 2014 at 01:23:27PM -0600, Stephen Warren wrote:
>> On 05/22/2014 12:21 PM, Sascha Hauer wrote:
>>> On Thu, May 22, 2014 at 10:16:35AM -0600, Stephen Warren wrote:
>>>> On 05/22/2014 09:30 AM, Sascha Hauer wrote:
>>>>> Hi all,
>>>>>
>>>>> The wish to have persistent MMC block device names for passing a suitable
>>>>> root=/dev/mmcblkX option came up several times already and has been discussed
>>>>> at least in these threads:
>>>>>
>>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/109984.html
>>>>> https://www.mail-archive.com/linux-mmc@vger.kernel.org/msg22104.html
>>>>> http://comments.gmane.org/gmane.linux.kernel.mmc/21519
>>>>>
>>>>> Several patches have been proposed to nail the slot index to a known number.
>>>>> Arguments against these patches were:
>>>>>
>>>>> - Use an initrd and locate the correct root device there
>>>>>   even Thomas who suggested this admitted this would be painful to do
>>>>> - use root=UUID= or root=PARTUUID=
>>>>>   This generally works but has an important downside. With the UUID
>>>>>   approach devices which should boot from the internal eMMC may start
>>>>>   booting from an external SD slot when somebody deliberately inserts
>>>>>   a SD card with the same UUID.
>>>>>
>>>>> The following patches should have the technical issues fixed. It works
>>>>> by counting the mmc aliases in the devicetree during initialization of
>>>>> the mmc framework. Those slot numbers will never be assigned to other
>>>>> hosts.
>>>>
>>>> Does it solve the following, which AFAIK has always been the primary
>>>> argument against aligning block device IDs with controller IDs:
>>>>
>>>> - User inserts SD card into MMC controller ID (or alias) 1.
>>>> - /dev/mmcblk1 now exists
>>>> - Mount /dev/mmcblk1 on /mnt/tmp
>>>> - User removes that SD card
>>>> - /dev/mmcblk1 still exists, since it's mounted so can't be deleted
>>>> after the card removal.
>>>> - User inserts SD card into MMC controller ID (or alias) 1.
>>>> - /dev/mmcblkN (N is something other than 1) now exists
>>>>
>>>> Now, the block device ID must be != the original ID, since two block
>>>> devices exist.
> 
> We could limit this to non-removable devices. This problem cannot occur
> there. Would that be acceptable?

That might work.

Re: adding aliases to mmc ... again

[Sascha Hauer]

On Thu, May 22, 2014 at 01:23:27PM -0600, Stephen Warren wrote:
> >> Does it solve the following, which AFAIK has always been the primary
> >> argument against aligning block device IDs with controller IDs:
> >>
> >> - User inserts SD card into MMC controller ID (or alias) 1.
> >> - /dev/mmcblk1 now exists
> >> - Mount /dev/mmcblk1 on /mnt/tmp
> >> - User removes that SD card
> >> - /dev/mmcblk1 still exists, since it's mounted so can't be deleted
> >> after the card removal.
> >> - User inserts SD card into MMC controller ID (or alias) 1.
> >> - /dev/mmcblkN (N is something other than 1) now exists
> >>
> >> Now, the block device ID must be != the original ID, since two block
> >> devices exist.
> > 
> > No, it shouldn't solve that, but it's out of scope for this patch. All
> > it solves is to reliably find the rootfs. If the card containing your
> > rootfs is removed you are in trouble anyway and it won't help if it gets
> > the same mmcblkno once it's plugged again. For other devices which don't
> > contain the rootfs there are enough possibilities to find them in userspace.
> 
> I don't think there should be any special cases for the root fs.
> 
> I don't think the disadvantage of the UUID= or PARTUUID= issue you
> mention enough is really an issue in general. If it is for some
> platform, then the root fs should be cryto-signed and validated to
> prevent someone from using the wrong root fs.

That argument came up here aswell. Crypto signing would prevent the Kernel
from starting the wrong userspace, but it would not start the correct one
either.
Crypto signing is quite a heavy approach for just making sure to boot from a
particular device.
Booting with UUID= is fine for several usecases, but I can't really
understand why it shouldn't be possible to point with the finger to the
bootdevice and just boot it. Instead we can just say "boot some device that
looks like this one".

Speaking of which my preferred solution is another one. As a bootloader
developer it really annoys me that I don't have the possibility to tell
the kernel to boot a particular device. What I really want to do is to
pass a devicetree phandle to the kernel for the rootfs (Or a device path
for the EFI/ACPI guys). This would solve a whole lot of problems here.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: adding aliases to mmc ... again

[Stephen Warren]

On 05/23/2014 03:23 AM, Sascha Hauer wrote:
...
> Speaking of which my preferred solution is another one. As a bootloader
> developer it really annoys me that I don't have the possibility to tell
> the kernel to boot a particular device. What I really want to do is to
> pass a devicetree phandle to the kernel for the rootfs (Or a device path
> for the EFI/ACPI guys). This would solve a whole lot of problems here.

Why not implement a root= kernel cmdline option that provides exactly that?

Re: adding aliases to mmc ... again

[Sascha Hauer]

On Fri, May 23, 2014 at 10:01:53AM -0600, Stephen Warren wrote:
> On 05/23/2014 03:23 AM, Sascha Hauer wrote:
> ...
> > Speaking of which my preferred solution is another one. As a bootloader
> > developer it really annoys me that I don't have the possibility to tell
> > the kernel to boot a particular device. What I really want to do is to
> > pass a devicetree phandle to the kernel for the rootfs (Or a device path
> > for the EFI/ACPI guys). This would solve a whole lot of problems here.
> 
> Why not implement a root= kernel cmdline option that provides exactly that?

That's the plan, yes. This will take some time though. To make this work
we'll need bindings devices which are normally autoprobable (MMC, USB).
UBI would need a binding. We'll need bindings for DOS/GPT partitions.
I expect some opposition there...
At least for USB bindings already exist that just have to be
implemented.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |