Re: adding aliases to mmc ... again

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx/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 |
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux