On 4/25/2012 2:46 PM, Brian C. Lane wrote:
So I wonder, why do we do this at all? Why not just use largest_partnum? The reason why I reverted instead of just switching to using largest is that I don't know if there was a good reason for always doing the first 16 partitions or not.
In the normal path the partition table can have more partitions than the kernel supports, so you need to not try to add more than what the kernel can handle. The dm code was probably loosely based on the normal path but it was hard coded to 16 rather than using _device_get_partition_range() to get the actual value.
Since there really isn't a limit for dm devices, it probably should just use largest_partnum, or the whole function should go away entirely as in my refactorization patch.
