Hi, Chris Ball wrote: > > Please could you send a version of the patch that supports power-on r/o > but not perm r/o, and perhaps also post userspace code for submitting > the perm r/o command through the ioctl interface? (Perhaps this code > should eventually be submitted to a disk management tool..)
Ok and ok, we will lose the permanent ro-locking and supply sample code for future reference. > Also, it looks like it's possible to set read-only for the whole > device, > as well as for boot partitions. Could you update the patch to allow > setting power-on r/o for the entire card, not just the boot partitions? Will give it a shot! > > 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 > > I don't follow why this node is necessary, instead of just having the > nodes in the mmcblkXbootY/ directories. Could you explain? This was meant to reflect that ro-locking the boot partitions is actually done per card and not per boot partition (so if you lock one boot partition, the other one is locked as well). Is there another way of making this connection clear? Maybe it will be enough to mention it in the Documentation? > echo 1 > /sys/block/mmcblkXbootY/ro_lock_until_next_power_on > > to lock just a boot partition, and: > > echo 1 > /sys/block/mmcblkX/ro_lock_until_next_power_on > > to lock the entire card (which will cover the boot partition too), with > echo 0 to unlock. Ok, this looks good. However, writing 0 will not unlock since the card needs to be power cycled. > Other review comments: I noticed that your pr_*(); statements are > missing "\n"s on the end, and you should add documentation on the new > sysfs nodes to: > Documentation/mmc/mmc-dev-parts.txt Ok! > I think the overlap between your patch and Andrei's > mmcblkXbootY/force_ro > node is going to be confusing -- one operates purely in the kernel and > the other is sent to the card. Do you have any proposal for making the > difference clearer? I concur, the same can be said about general purpose partitions as well? Partitions that are configured in hardware rather than software. The current layout in sysfs does not reflect this difference either, below mmcblk0 we find mmcblk0p1 mmcblk0boot0 mmcblk0gp0 which are a mix of different partition types. Maybe separate sysfs trees in some way? I am afraid I'll have to pass this question back to you. Thank you all for your comments. Kind regards, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
