On Fri, Nov 20, 2015 at 4:18 PM, Patrick Georgi pgeorgi@google.com wrote:
So you think we're better off with one place to store the partition layout, a separate one to store what files belong where, and yet another one for the properties of those files, each with their own syntax and tooling?
Yes. I find it strange that you seem to imply this would make it more complex or otherwise undesirable. Your proposal is to use a common language, but spread the files that control all of this (including the layout, which I think is the thing that really needs to be together in one place to be readable) all over the place. I think we agree that declarations of individual files should go in the different source directories that relate to them, I just think that the layout should stay centralized to be easily comprehensible and modifyable.
When designing CBFS we definitely did have fixed locations in mind.
Sure, I'm definitely not trying to argue that... I'm just saying that I think this should change if we have a cleaner option. The old CBFS has done a good job for a long time, but it was designed for a very specific purpose (x86 ROMs, I believe even without IFDs?) and we are now trying to do many more things (ARM boards with different layout requirements, RO/RW split ROMs, individually updateable A/B copies of the same file sets) that it really doesn't support well. Let's face it, problems like "we need to control the order in which we add files because otherwise the fixed location placement breaks" are really ugly and we should try to find a design that removes them completely.
Can anyone see some concrete problems with Kevin's suggestion?
I actually think Kevin's suggestion was pretty much the same thing we're proposing anyway. It's just that he suggested adding regions one at a time per cbfstool invocation, while the .fmd format is designed to read the complete region layout from a file at image creation (which I think is nicer because it makes the layout very easy to read... if you did the thing with commands, you'd effectively still end up having a list of those region-defining commands in some Makefile).
The "little additional metadata" that Kevin said we needed *is* the FMAP. Think about it, how else would you store a list of regions with hardcoded bounds? This whole thing really started as an idea for a "CBFS partition layout" (http://www.coreboot.org/User_talk:MrNuke/CBFS_Ideas), until we realized that the difference between any "partition table" format we could come up with and an FMAP was so negligible that we might as well keep the established format with pre-existing tooling (most importantly flashrom support).