Proposal: Soil Feature Guards

[ctiedt]

There are some differences in features between current Soil implementations. Some of this is because of differing states of maintenance, but certain features may not make sense for some use cases.

For example, the kernel module omits floating point support, since floating point arithmetic is not generally usable in the Linux kernel. Also, some syscalls, e.g. those related to graphics, may not be always be available.

Proposal

Introduce a new section kind features. I see two possible implementations here:

• Make the section word-sized and define each bit to toggle a feature from a fixed list, to be defined in the specification.
• Make the section a list of key-value pairs of feature names to values.

While the first solution is more efficient in terms of binary size, the second allows for greater flexibility in feature definition and could also allow for non-boolean features.

[phkeese]

Related: #5 I really like the key-value section but I think a more basic "which version of the spec are we currently referring to" kind of guard would also help to catch errors during development of said spec.