10 comments:
Patch Set #17, Line 244: default !NO_RELOCATABLE_STAGES
This equates STAGE_CACHE with RELOCATABLE_STAGES/RELOCATABLE_RAMSTAGE. Is that really a good assumption to make? I understand that it is true at this point for the current platforms. But what about this: If a platform does not support relocatable ramstage, but still wants to use stage cache to stash refcode/S3 data for example, would that be a valid use case?
ramstage to be built as a
relocatable module
Is it right to mention ramstage here since you seem to be making it more of a generic relocatable stages option now?
It would be good to mention that the platform is responsible for providing storage for this external stage cache.
Patch Set #17, Line 262: select RELOCATABLE_MODULES
RELOCATABLE_MODULES can be set to true based on !NO_RELOCATABLE_STAGES? i.e. EXTERNAL_STAGE_CACHE or CBMEM_STAGE_CACHE don't need to select them, right?
Patch Set #17, Line 264: enable
enables
Patch Set #17, Line 266: chiset
chipset
Patch Set #17, Line 272: enable
enables
Patch Set #17, Line 279: NO_RELOCATABLE_STAGES ||
This condition does not look completely right to me. I believe it should just be based on !HAVE_ACPI_RESUME. Same comment as above for STAGE_CACHE.
File src/arch/x86/Makefile.inc:
Patch Set #17, Line 378: CONFIG_STAGE_CACHE
It just feels a bit twisted that ramstage being a rmodule is dependent on availability of stage cache. Should we still retain CONFIG_RELOCATABLE_RAMSTAGE?
File src/include/stage_cache.h:
Patch Set #17, Line 40: CONFIG_NO_STAGE_CACHE
This should be updated as well.
To view, visit change 33116. To unsubscribe, or for help writing mail filters, visit settings.