Hi Linus, On 3/2/18 4:53 AM, Linus Walleij wrote: > On Tue, Feb 27, 2018 at 12:33 PM, Harish Jenny K N > <harish_kandiga@xxxxxxxxxx> wrote: > >> From: Andrew Gabbasov <andrew_gabbasov@xxxxxxxxxx> >> >> Since RPMB area is accessible via special ioctl only and boot areas >> are unlikely to contain any partitions, exclude them all from listing >> in /proc/partitions. This will hide them from various user-level >> software (e.g. fdisk), thus avoiding unnecessary access attempts. >> >> Signed-off-by: Andrew Gabbasov <andrew_gabbasov@xxxxxxxxxx> >> Signed-off-by: Harish Jenny K N <harish_kandiga@xxxxxxxxxx> > Makes sense to me, at least it makes the problem smaller not bigger. > Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx> > >> The main intention of the patch was to not have RPMB device in /proc/partitions. >> Boot partitions are also unlikely to have any partitioning, so it made sense to >> treat them the same way as RPMB and not list in /proc/partitions. >> Now I see that RPMB is converted to a character device and this change >> may not be required for RPMB. > It certainly does not hurt, even if this code path is not called > for the RPMB partition anymore (luckily). > > On a general note, I do not feel the work with boot partitions or > the general purpose partitions is finished. > > In a lecture I pointed out that: > > dd if=/dev/sda of=sda.img > > Gives an image of the whole device, and you can restore the > device by doing the inverse of that command. > > For MMC devices, > > dd if=/dev/mmcblk0 of=mmcblk0.img > > does NOT have the same nice property. Instead, since the > special partitions are their own devices and not part of the main > device, they have to be backed up separately. > > IMO this breaks the user contract of how a device vs a partition > works. > > What we need to do is make the "special partitions" part of the > main block device and stop spawning these special block > devices for each boot partions or general partitions. In addition, > each of these boot partitions or general partitions will get their > own block queue and state container which is not cheap in > runtime memory footprint terms. > > So what I want to do (unless someone beats me to it) it to come > up with some way making boot and general partitions part > of the main block device. Possibly the core kernel partitioning > code needs to be augmented. The tentative idea is to just > put the sectors representing these partitions after the main > block device and access them from there, with an offset. I don't think that hiding the Boot and RPMB will resolve the problem described above. Boot partition (same as RPMB) in eMMC device is a separate "physical" partition. It has its own logical address range and different from general partition characteristics. >From the protocol - the access to this partition it requires switch partition command. It can be accesses during the boot sequence before the general/userdata partition is mounted. >From the device side - it can be managed in totally different manner (SLC vs. MLC blocks, etc.) I think it completely makes sense to allow access to Boot partition from the user space. For example - to allow R/W the boot image. AFAIK, in case of SCSI/UFS devices - Boot LUN's are represented as separate block device partitions (/dev/sdb, dev/sdc...). Shouldn't we have the same for eMMC? > 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 ��.n��������+%������w��{.n�����{��i��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
