> > I'll expose the coreboot tables using a sysfs driver, which then can be > > used by coreboot tools instead of accessing /dev/mem. As it holds the > > FMAP and "boot media params" that's all I need for now. > > > > The downside is that the userspace tools need to be keep in sync with > > the binary interface the coreboot tables are providing.
Well, in the other version the kernel needs to be kept in sync instead. No matter where you do the parsing, something needs to be kept in sync. I think userspace would be easier, especially if we would host a small userspace library in the coreboot repository that other tools could just link. > I'd rather we export this information in sysfs via some coreboot_fmap > class and then make the "boot media params" another property of one of > the fmap devices. Then userspace can search through all the fmap devices > and find the "boot media params" one. Is anything else needed? Okay, this is the fundamental question we need to answer first... do you really think it's better to add a separate interface for each of these, Stephen? The coreboot table[1] currently contains 49 entries with all sorts of random firmware information, and most of these will never be interesting to the kernel. Do we want to establish a pattern where we add a new sysfs interface for each of them whenever someone has a use case for reading it from userspace? I think this might be a good point to implement a generic interface to read any coreboot table entry from userspace instead, and say that if the kernel doesn't need the information in a specific entry itself, it shouldn't need to know how to parse it. [1] https://review.coreboot.org/cgit/coreboot.git/tree/src/commonlib/include/commonlib/coreboot_tables.h