Attention is currently required from: Hsuan-ting Chen, Yu-Ping Wu. Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/63115 )
Change subject: libpayload: Add CONFIG_LP_ELOG and its dependency ......................................................................
Patch Set 9:
(1 comment)
File payloads/libpayload/Makefile.inc:
https://review.coreboot.org/c/coreboot/+/63115/comment/ba768966_683171bb PS9, Line 51: classes-$(CONFIG_LP_ELOG) += elog "libc" in libpayload isn't really a C library, it's a catchall bucket for all the other stuff that isn't separated into its own library. All the drivers, coreboot table stuff, etc. all go in there too. I don't think it makes sense to draw a line at elog (even if more code will be added, it's not gonna be that much in total... the USB stack alone would be much larger).
We can talk about a general reorganization if you want, but this patch is probably not the time for it. And if we do I'm also not sure where the point is in splitting everything out so fine-grainedly. I doubt anyone actually uses any of these individual libraries (depthcharge just links libpayload.a and most other payloads probably do too). I think it may make sense for totally separate code bases (curses, vboot) but for the other stuff that's just a handful of files solely written for and maintained in the libpayload repo each (e.g. libcbfs, compression algos, etc.) I don't really see the point of splitting that out.
Though it is still a small file only, I am not sure if we should prevent including it for the non-ChromeOS platforms since I am not familiar with them.
We can change it if someone complains, of course, but by default I wouldn't assume it's necessary. Library code that's not referenced doesn't hurt anyone, the only concerns here are symbol clashes (unlikely) and build times (negligible for so little code).