linux-mmc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: linux-mmc@vger.kernel.org, Dirk Behme <dirk.behme@de.bosch.com>,
	Fabio Estevam <festevam@gmail.com>,
	ptx@pengutronix.de
Subject: Re: adding aliases to mmc ... again
Date: Fri, 23 May 2014 11:23:59 +0200	[thread overview]
Message-ID: <20140523092359.GG15686@pengutronix.de> (raw)
In-Reply-To: <537E4EAF.5000309@wwwdotorg.org>

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 |

  parent reply	other threads:[~2014-05-23  9:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-22 15:30 adding aliases to mmc ... again Sascha Hauer
2014-05-22 15:30 ` [PATCH 1/2] of: Add helper for getting the maximum alias index for a stem Sascha Hauer
2014-05-22 15:30 ` [PATCH 2/2] mmc: Allow setting slot index via devicetree alias Sascha Hauer
2014-05-22 16:16 ` adding aliases to mmc ... again Stephen Warren
2014-05-22 18:21   ` Sascha Hauer
2014-05-22 19:23     ` Stephen Warren
2014-05-23  8:29       ` Michael Olbrich
2014-05-23 16:02         ` Stephen Warren
2014-05-23  9:23       ` Sascha Hauer [this message]
2014-05-23 16:01         ` Stephen Warren
2014-05-24  5:10           ` Sascha Hauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140523092359.GG15686@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=dirk.behme@de.bosch.com \
    --cc=festevam@gmail.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=ptx@pengutronix.de \
    --cc=swarren@wwwdotorg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).