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

proposal: x/sys: Add the "unsafe" mmap() family of functions #56123

Open
piotr-sneller opened this issue Oct 10, 2022 · 1 comment
Open

proposal: x/sys: Add the "unsafe" mmap() family of functions #56123

piotr-sneller opened this issue Oct 10, 2022 · 1 comment
Labels
Milestone

Comments

@piotr-sneller
Copy link

The current implementation of the Mmap wrappers for the Unix-derived OSes does not dispatch directly to the relevant syscall but relies on the mmapper layer. The mmapper adds address range validation and returns EINVAL for the ranges not matching the content of the mapping registry. While it might be arguably correct for most of the use cases, it also prevents partial Munmaps and similar valid parts of the pretty rich mmap semantics. I suggest that the existing implementation should be left as-is, but undisturbed access to the underlying OS primitives should also be provided. The scope of the extension would be minimal, as the low-level part already is there -- the package should just export more entry points. The naming details are irrelevant to me, so I leave them unspecified: I will be equally happy with MmapUnsafe as with MmapRaw.

The only suggestion I'd make is the return type: the functions should operate with uintptr, as their WinAPI VirtualAlloc() counterparts do. Wrapping the uintptr in a slice just to unwrap it in the follow-up step to recover the uintptr adds no value. I'll make the slice when I'm done.

@gopherbot gopherbot added this to the Proposal milestone Oct 10, 2022
@ianlancetaylor
Copy link
Contributor

Can you write down the exact new API that you propose adding? Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Incoming
Development

No branches or pull requests

3 participants