Skip to content

Conversation

@ureeves
Copy link

@ureeves ureeves commented May 18, 2025

Currently both userfaultfd and userfaultfd-sys always load libclang dynamically. This commit keeps this as the default behavior but adds the "static" and "runtime" features. The "static" feature will statically link libclang, while "runtime" will load libclang at runtime.

Users using default-features=false will need to specify features = ["runtime"] to maintain current behavior, but they should be in the minority, given that neither crate currently has default features.

Currently both `userfaultfd` and `userfaultfd-sys` always load libclang
dynamically. This commit keeps this as the default behavior but adds the
"static" and "runtime" features. The "static" feature will statically
link libclang, while "runtime" will load libclang at runtime.

Users using `default-features=false` will need to specify
`features = ["runtime"]` to maintain current behavior, but they should
be in the minority, given that neither crate currently has default
features.
@ureeves
Copy link
Author

ureeves commented May 18, 2025

I see the workflow is failing due to github having retired their ubuntu 20 images. I also see there's a problem with simply updating to the more recent ubuntu 22 images, since they're running kernel 6.8 and as a consequence the syscall path for creating a file descriptor would no longer be tested.

I can see at least two options for addressing this problem:

1.) Modify the public API of the crate to allow the user to choose which method to use - either use the syscall or the ioctl.
2.) Introduce features, much like the one introduced in this PR, controlling which methods of creating a file descriptor are allowed.

@bchalios
Copy link
Collaborator

Hi @ureeves and thanks for the contribution. I would be in favour of the latter solution (introducing features) where, by default, we 'd be trying to use /dev/userfaultfd to create the file descriptor. I wouldn't be in favour of exposing the option to the public API. Do you see any reasons why we would try to do that?

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.

2 participants