Skip to content

Introduce krun_has_feature() API#525

Merged
tylerfanelli merged 1 commit intocontainers:mainfrom
mtjhrc:has_feature_api
Feb 5, 2026
Merged

Introduce krun_has_feature() API#525
tylerfanelli merged 1 commit intocontainers:mainfrom
mtjhrc:has_feature_api

Conversation

@mtjhrc
Copy link
Collaborator

@mtjhrc mtjhrc commented Feb 3, 2026

Introduce a function to query at runtime whether a specific feature was enabled at build time. This allows applications to check for optional capabilities before attempting to use them. This is especially useful for our tests and examples.

@mtjhrc
Copy link
Collaborator Author

mtjhrc commented Feb 3, 2026

Is this even a good idea? I mean an alternative could be checking if the related symbol names exists with dlysm, but we are not always constituent on whether the function exists or just returns ENOTSUP or doesn't even return any error at all e.g. krun_set_gpu_options

@mtjhrc mtjhrc marked this pull request as ready for review February 3, 2026 17:12
@mtjhrc mtjhrc force-pushed the has_feature_api branch 2 times, most recently from f469a26 to 072693c Compare February 3, 2026 17:21
"TEE" => cfg!(feature = "tee"),
"SEV" => cfg!(feature = "amd-sev"),
"TDX" => cfg!(feature = "tdx"),
"NITRO" => cfg!(feature = "nitro"),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#521 changes NITRO to AWS_NITRO, perhaps that could be modified here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that is nicer.

Hmm, perhaps we should we also change these for consistency?
TDX -> INTEL_TDX
SEV -> AMD_SEV

I mean we should probably change the name in the Makefile too, but this seems like a more user friendly naming convention.

Copy link
Member

@jakecorrenti jakecorrenti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this idea and it reminds me of KVM's feature/extension API.

Rather than using strings, I wonder if we should do something similar to KVM where we have something along these lines:

// features are integers exposed by a public constant
#define KRUN_FEATURE_NET 0
#define KRUN_FEATURE_BLK 1
...
#define KRUN_FEATURE_VIRGL_RESOURCE_MAP2 10

// user calls API to check feature using the constant instead of hard-coded string
int ret = krun_has_feature(KRUN_FEATURE_NET);

@mtjhrc
Copy link
Collaborator Author

mtjhrc commented Feb 4, 2026

Rather than using strings, I wonder if we should do something similar to KVM where we have something along these lines:

Yeah, I've changed it to use integers.

jakecorrenti
jakecorrenti previously approved these changes Feb 4, 2026
Copy link
Member

@jakecorrenti jakecorrenti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Copy link
Member

@tylerfanelli tylerfanelli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To stay in accordance with other APIs.

Introduce a function to query at runtime whether a specific feature
was enabled at build time. This allows applications to check for
optional capabilities before attempting to use them.

This is especially useful for our tests and examples.

Signed-off-by: Matej Hrica <mhrica@redhat.com>
Copy link
Member

@tylerfanelli tylerfanelli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks.

@tylerfanelli tylerfanelli merged commit 4d11a0e into containers:main Feb 5, 2026
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants