loader: provide a features table for binary compatibilty advertisement

[kevans]

Summary

Prototype of the interface I think we should provide here... liblua
provides name => desc mappings for all of the features that *are*
enabled, we use a shim in core (hasFeature) in case the underlying
binary doesn't even have feature support yet (in which case we can
assume it doesn't have the feature either).

This would be used in lua as core.hasFeature("EARLY_ACPI")

[imp]

Generally I like it.... it would be nice to take it two steps further. (1) man page update and (2) how do we solve the current acpi problem with this... I like the base... 32 or 64 features before we need something more complex, which should be enough for years or decades given the historic rate of adding these things...

[kevans]

In D42695#974021, @imp wrote:

Generally I like it.... it would be nice to take it two steps further. (1) man page update and (2) how do we solve the current acpi problem with this... I like the base... 32 or 64 features before we need something more complex, which should be enough for years or decades given the historic rate of adding these things...

We would either replace the core.isX86() call you added with not core.hasFeature("EARLY_ACPI") so that we err on the side of caution and load ACPI bits if we can't tell at all. Failing to load the module if it doesn't exist for the current platform is already not an error, so it's a mild nuisance that's fixed by updating their loader.

[kevans]

Add feature information to various manpages, we don't currently duplicate the
mapping table into the manpage.

Flesh it out further for the ACPI case, but that's been moved to a separate
review.

[imp]

I like this.
No FORTH support, but we gotta have a hard conversation about that.

stand/libsa/features.c

7

Consider yhe new short form w/o all this boilerplate