Hi Ulf, Johan,

----- Original Message -----
> From: "Ulf Hansson" <[email protected]>
> To: [email protected], "Chris Ball" <[email protected]>
> Cc: "Per Forlin" <[email protected]>, "Ulf Hansson" 
> <[email protected]>, "Lee Jones"
> <[email protected]>, "Johan Rudholm" <[email protected]>, "John 
> Beckett" <[email protected]>
> Sent: Friday, October 21, 2011 9:17:23 AM
> Subject: [PATCH] mmc: boot partition ro lock support
> 
> From: Johan Rudholm <[email protected]>
> 
> Enable boot partitions to be power and permanently read-only locked
> via
> a sysfs entry. There will be one sysfs entry for the main mmc device:
> 
> /sys/block/mmcblkX/boot_partition_ro_lock
> 
> and one for each boot partition:
> 
> /sys/block/mmcblkXbootY/ro_lock
> 
> The boot partitions are power or permanently locked by writing
> "pwr_ro"
> or "perm_ro" to one of the files.
> 
> Signed-off-by: Ulf Hansson <[email protected]>
> Signed-off-by: John Beckett <[email protected]>
> Signed-off-by: Johan Rudholm <[email protected]>
> ---

What does power locking do that force_ro currently doesn't achieve?

The permalocking brick-potential (more like paper-weight-potential) is IMO 
unacceptably
high that something like this is just accessible via a sysfs attribute. This is 
exactly
why the boot partitions were put under force_ro, so that some poor sap wouldn't 
end up
nuking the boot partitions (with obvious consequences), and permalocking seems 
even nastier.

At a bigger picture, I'm uncertain what the point of this is. It adds code 
complexity for,
a generally rare and possibly self-destructive operation. This is like the GP 
partitioning 
support - it's a once-a-time (and unrecoverable) operation usually done at 
manufacturing (or initial
provisioning time) that shouldn't be even exposed to the general purpose user. 
This would be a
good use of that arbitrary-CMD ioctl interface John Calixto put in.

Thanks,
A
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to