Messages in this thread | | | Date | Wed, 29 Aug 2012 11:51:12 +0300 | From | Shmulik Ladkani <> | Subject | Re: [PATCH v2] mtd: cmdlinepart: fix the wrong partitions number when truncating occurs |
| |
On Wed, 29 Aug 2012 11:16:05 +0300 Artem Bityutskiy <dedekind1@gmail.com> wrote: > On Sun, 2012-08-26 at 09:06 +0300, Shmulik Ladkani wrote: > > root 100m@0 > > kernel 100m@100m > > rootfs 800m@200m (truncated) > > user 0@1g (truncated) > > rest 0@1g > > Who would benefit from having those 2 0-sized partitions and how? How > many users/scripts would be confused by this (these 2 ghost partitions > would be visible in /proc/mtd and sysfs)? How much RAM would we spend > for creating sysfs files and directories for these ghost partitions > (note, one sysfs file costs a couple KiB I thing, because 'sizeof > (struct inode)'). > > While you suggestion is clever, do we really benefit from this?
Artem, please note this is just a side effect of what I've suggested (that its, continue parsing after first truncated partition), not a real use case I'd expect and intentionally wish to support.
I am used to specify partitions explicitly using size@offset (specifying offset for all parts, even if sometimes adjacent), and sometimes in an unsorted fashion. I never defined some partition that got truncated, so the whole discussion is theoretical to _my_ usecase.
The only benefit of continuing to parse, is that if there _are_ later partitions which are defined _explicitly_ with an offset, whose location is _before_ the truncated partition, these would still be parsed and registered.
Not so important, and would rarely happen, but simplistic and naive.
And reagrding 0 sized partitions, we can always skip these.
Regards, Shmulik
| |