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: Thu, 22 May 2014 20:21:34 +0200	[thread overview]
Message-ID: <20140522182134.GD15686@pengutronix.de> (raw)
In-Reply-To: <537E22E3.3010601@wwwdotorg.org>

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 |

  reply	other threads:[~2014-05-22 18:21 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 [this message]
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
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=20140522182134.GD15686@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).