Stop converting "=y" and "=m" to "true" for the raw feature values used
in "kernel.config" custom rule processing.
In practice, this means that to check if a kernel config flag has been
set to "y" or "m", one needs to explicitly check for both of the values:
matchFeatures:
- feature: kernel.config
matchExpressions:
FOO: {op: In, value: ["y", "m"]}
instead of (how it used to be):
matchFeatures:
- feature: kernel.config
matchExpressions:
FOO: {op: IsTrue}
The legacy kconfig custom rule is unchanged as are the
kernel-config.<flag> feature labels.
Create a new package pkg/apis/nfd/v1alpha1 and migrate the custom rule
expressions over there. This is the first step in creating a new CRD API
for custom rules.
Implement a framework for more flexible rule configuration and matching,
mimicking the MatchExpressions pattern from K8s nodeselector.
The basic building block is MatchExpression which contains an operator
and a list of values. The operator specifies that "function" that is
applied when evaluating a given input agains the list of values.
Available operators are:
- MatchIn
- MatchNotIn
- MatchInRegexp
- MatchExists
- MatchDoesNotExist
- MatchGt
- MatchLt
- MatchIsTrue
- MatchIsFalse
Another building block of the framework is MatchExpressionSet which is a
map of string-MatchExpression pairs. It is a helper for specifying
multiple expressions that can be matched against a set of set of
features.
This patch converts all existing custom rules to utilize the new
expression-based framework.
Separate feature discovery and creation of feature labels in the kernel
source.
Move kernelutils from source/internal back to the source/kernel package.
Change the kconfig custom rule to rely on the FeatureSource interface
(GetFeatures()) of the kernel source.
Also, add minimalist unit test.
