Skip to content

[Refactor] Add vmmap-related calls [mmap / munmap / brk / sbrk] #142

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

Draft
wants to merge 3 commits into
base: simple-syscall
Choose a base branch
from

Conversation

celinehoang177
Copy link
Contributor

  • Added implementation of mmap / munmap / brk / sbrk with new type conversion

@Yaxuan-w Yaxuan-w requested a review from rennergade April 16, 2025 18:58
@Yaxuan-w Yaxuan-w changed the title Add vmmap-related calls [mmap / munmap / brk / sbrk] [Refactor] Add vmmap-related calls [mmap / munmap / brk / sbrk] Apr 16, 2025
off_cageid: u64,
) -> i32 {
// TODO: Check will perform in the below logic??
println!("[mmap_syscall] selfcageid: {:?}, FD Cageid: {:?}", cageid, vfd_cageid);
Copy link
Contributor

Choose a reason for hiding this comment

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

is this supposed to still be here?

Copy link
Member

Choose a reason for hiding this comment

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

Removed

///
/// # Returns
/// * `u32` - Result of the `mmap` operation. See "man mmap" for details
pub fn mmap_syscall(
Copy link
Contributor

Choose a reason for hiding this comment

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

I see that we combined all of the mmap logic into one place here, which is a good first step, but it turns out pretty hard to read. It would be cool if we could separate this out with comments a bit or find places where it would make sense to internally functionize.

Copy link
Member

Choose a reason for hiding this comment

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

I'm also thinking about priority here. Maybe we could open an issue to document this and optimize this later?


// we are replacing munmap with mmap because we do not want to really deallocate the memory region
// we just want to set the prot of the memory region back to PROT_NONE
// Directly call libc::mmap to improve performance
Copy link
Contributor

Choose a reason for hiding this comment

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

does this improve performance?

Copy link
Member

Choose a reason for hiding this comment

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

This is pasting from rawposix...

Copy link
Contributor

@rennergade rennergade left a comment

Choose a reason for hiding this comment

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

Pretty good, the internal functions could possibly be cleaner but I'm not sure thats worth the effort here.

@Yaxuan-w Yaxuan-w requested a review from rennergade June 26, 2025 02:41
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