1 comment:
File payloads/libpayload/drivers/cbmem_console.c:
Patch Set #1, Line 64: cbmem_console_p
However, inside the structs, there may be more pointers and those have to be physical (because we refer to the original tables).
Are there really? I can't see any obvious examples right now. In general, pointers should never be directly in structures that are meant to be accessed across program boundaries (because pointer size might change), they should always be converted to uint32_t or uint64_t. If we have examples where they aren't, we should probably just fix that instead.
Sorry, I didn't mean C pointers. Just addresses, they are already uints.
> Don't point to anything outside the payload unless it is supposed to be written to (e.g. MMIO, CBMEM console).Hmm... that's copying a lot of stuff even though most of it is often not needed (e.g. all the build information). I think it might also get confusing with the difference between "supposed to be written to" and the rest. Can't we just make it all uintptr_t instead?
I know it would leave some potential for confusion. But I just fail to see
the point of `struct sysinfo` if we don't import the information. If it's
merely a collection of pointers to CB stuff without any abstraction, we'll
depend on the CB structures everywhere. We could as well just drop `sysinfo`
and discover things on demand. Then nobody would have to ask why we keep
all those physical pointers :)
To view, visit change 37478. To unsubscribe, or for help writing mail filters, visit settings.