Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/31766 )
Change subject: Documentation: Explain FMAP and FMD ......................................................................
Patch Set 5:
(1 comment)
https://review.coreboot.org/#/c/31766/3/Documentation/lib/flashmap.md File Documentation/lib/flashmap.md:
https://review.coreboot.org/#/c/31766/3/Documentation/lib/flashmap.md@45 PS3, Line 45: programmed (or after some security policy is enabled).
For example, all the WP_RO sections in chromeos.fmd may include FMAP_AREA_RO (and yes it's nested).
But what does that actually say that isn't already said by the WP_RO region? Having multiple redundant ways to describe the same thing is not good -- it just opens up the possibility for inconsistencies. As long as Chrome OS factory scripts (and whatever else wants to read WP information from the FMAP) only checks for WP_RO, adding a second mechanism is pointless and can only cause problems.
A similar thing goes for COMPRESSED... I don't see a scenario where this would really be helpful. There are no global similarities between FMAP sections anyway. The contents of every section are completely specific to the section name, i.e. you cannot assume that they all contain code or anything. If you want to inspect the contents of a section you have to first figure out what that specific section means anyway. A flag like this would only make sense if we had some global, section-independent FMAP compression scheme, and there are no plans to have that atm.
I think we should only have flags when someone has a concrete, real-world use case and there's actually code doing something with it somewhere (like PRESERVE). Otherwise the flag would be useless because nobody knows what exactly it's supposed to do and under what circumstances to set them, so you couldn't ever rely on it being set correctly.