Again then this becomes an inconsistency on Chrome OS. FSP lives in RO, RW-A, and RW-B regions. RW-A and RW-B will be CBFS. So do make it it partly CBFS and partly FMAP such that the code is consistent to use FMAP APIs throughout? In my opinion that isn't appropriate. From a "change this little bit of code here" thing it's doable. But from looking at source code I standpoint such it's inconsistent. Sure FMAP would be used in certain places, but I'd argue those are in the infrastructure parts that many people porting things don't deal with. I don't want people to head scratch where something should live and then figure out 1. how to access it and 2. how to add it properly. The latter is still not plumbed in anywhere in the build system.
Okay, I guess we disagree on that one, then. In my opinion, the biggest problem and inconsistency here is that we have a CBFS file that needs to be placed at an exact offset (breaking the whole concept of CBFS as a "file system" that can transparently manage its space allocation). I think this is something that was done in the past for lack of a better option, but that can and should be fixed when a better tool (FMAP) is available. In my recollection/perspective, this was the biggest reason we decided to combine CBFS and FMAP in the same image in the first place (as opposed to porting all the Chrome OS / vboot tools over to access CBFS and have the whole Chrome OS image be a single (enhanced) CBFS)... because we acknowledged that FMAP's strengths (global lookup table, rigid regions that can be exactly aligned to custom offsets or erase blocks) are completely different and complementary to CBFS's strengths (organizing many small files in a compact, easy to manage format with automatic, opaque layout).
If Intel's architectural requirements force us to have a component that must be linked at an exact spot in the image, I think it would only be consistent to use the tool that we have which is meant for these sorts of things... FMAP. It makes the intention (of placing it *exactly there*) very explicit, and it frees up CBFS from weird requirements that you wouldn't expect (e.g. the RO CBFS must encompass that region, you need to pay attention to the order you add files in, etc.). If that makes the code that handles it more complicated that's unfortunate, and we should try to mitigate it where we can (maybe hide differences with an extra FSP access API, or have all chipsets keep it in its own FMAP section (maybe even in RW?) even though only some really need that, or find a way / ask Intel to separate the location-dependent part out into a separate blob)... but it still seems like a smaller price to me than keeping the separation of duties between FMAP and CBFS muddied and imposing all of those weird restrictions on the latter for this one special case.
I should probably stop arguing this because I don't even know the Intel code this is for... if you and all other x86 developers think the FSP really must go in CBFS I'll shut up. It's also really only tangentially related to the original discussion about the build system architecture... but I brought it up because some of the benefits Patrick's approach is trying to achieve (being able to better control CBFS file ordering) should be irrelevant in my opinion, and only even exist because of this problem.