Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libcontainer: make device creation interfaces public #1578

Merged
merged 1 commit into from
Feb 21, 2023

Conversation

ipuustin
Copy link
Contributor

I'm investigating how to implement device file support to runwasi in this PR: containerd/runwasi#68. In order to use libcontainer functions for device file creation, they would need to be public for use from other crates. I would be happy to hear feedback regarding whether or not this is the right way to approach this problem.

Another question has to do with the libcontainer test mocks. The libcontainer device creating functions, when compiled in test configuration, know how to mock system calls. Is there a way for exposing that to users outside of the crate too? Maybe having a different libcontainer feature selected in dev-dependencies?

@ipuustin ipuustin force-pushed the public-device-functions branch from 4ee6cc6 to c77dd2c Compare February 16, 2023 15:08
@codecov-commenter
Copy link

Codecov Report

Merging #1578 (c77dd2c) into main (8b0c44b) will decrease coverage by 0.01%.
The diff coverage is n/a.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1578      +/-   ##
==========================================
- Coverage   68.86%   68.86%   -0.01%     
==========================================
  Files         120      120              
  Lines       13058    13058              
==========================================
- Hits         8993     8992       -1     
- Misses       4065     4066       +1     

@Furisto
Copy link
Collaborator

Furisto commented Feb 19, 2023

Making Device public seems ok. I am hesitant add another feature flag to the crate as we already have quite a few and I do not want complicate it further without having a strong demand for this. How about we add a new_with_syscall() function that allows specifying the syscall implementation?

@Furisto Furisto self-assigned this Feb 19, 2023
@ipuustin
Copy link
Contributor Author

I think new_with_syscall() would be a great solution!

@Furisto Furisto merged commit 9285176 into youki-dev:main Feb 21, 2023
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