Add support for disk partitions

[Laczen]

@danieldegrasse @jfischer-no I am thinking about adding support for simple partitions on disks for zephyr. The idea would be to create a zephyr,simple-fixed-disk-partition that specifies the offset and size as sector multiples in the dts

As a first step I was thinking about adding uint32_t offset and uint32_t sector_count as variables to the disk-info structure (for a complete disk the offset would be zero and the sector_count retrieved from the disk.

As a second step the zephyr,simple-fixed-disk-partition would be introduced, which would then be a disk again but with the offset and sector_count taken from the dts.

What is your opinion on the idea ?

[jfischer-no]

There is no point in making it static. This has to be detected at runtime, e.g. SDCARDs are not static media. We should not have another broken storage subsystem.

[Laczen]

Thanks for your comment.

The addition of a offset and sector_count is not static at all and can be detected when a disk is inserted.

The proposal to allow simple-fixed-disk-partitions is static but clearly illustrated by their naming and could be a first step for partitioning information read from disks.

What storage subsystem is broken ?

[danieldegrasse]

@jfischer-no I agree, SD cards aren't static. However, in an embedded application, I would argue they often will be. Perhaps on an embedded device the overhead of parsing a partition header on disk is not worth the flexibility? I would have no issue with some form of support for runtime partition parsing in Zephyr, but I think we should keep smaller devices in mind and support some form of allocation determined at build time as well. What are your thoughts?

[stomschik-ask]

I agree that for most consumer applications, the partition information shall be extracted from MBR or GPT to be compatible with other devices like PCs. However, in deeply embedded applications which use eMMC instead of SD cards, static partitioning could be helpful for some specific use cases. We need for example more than one partition on eMMC and we must be able to automatically re-create the file system of the partitions on eMMC in case of an error. The requirement for recreation of the file systems is existing due to the limited data retention time of modern eMMC memories which may not be long enough to survive the storage time of our product. As the eMMC memory is non-removable, adding a MBR or GPT would just increase complexity and the MBR or GPT would also require automatic recreation in case of errors.

In the meanwhile, a loopback disk driver has been added to Zephyr. Unfortunately, this loopback disk driver supports only creating a new loopback disk device backed by a file at the specified path: it cannot be used to create a new loopback disk device at a specific offset and length of another disk device. Extending this loopback disk driver might be possible, though.