Patches to support shared memory in DragonWare - #11
Closed
tseli0s wants to merge 6 commits into
Closed
Conversation
tseli0s
added
enhancement
Hackish workaround to allow processes to transfer handles to other processes and therefore implement shared memory and everything else we need really fast and easily. Probably going to write a proper API for this in the future, but for now my priority is to get a simple shared memory application running. Signed-off-by: Aggelos Tselios <aggelostselios777@gmail.com>
There is a limit on how large a Section object can be due to kmalloc() design constraints, but this gives a single section a maximum addressable region of nearly two megabytes, plenty for very basic stuff like small files. In the meantime I should really think of something else, but for now, this is a quick way to get some heap running. Signed-off-by: Aggelos Tselios <aggelostselios777@gmail.com>
Will be needed to track how many processes have mapped the section and therefore avoid freeing shared memory, causing security vulnerabilities and bugs across programs. Signed-off-by: Aggelos Tselios <aggelostselios777@gmail.com>
Both are going to be used to do automatic reference counting instead of typing out the same if/else block every time. Will also be needed now that section objects have reference counting internally. Signed-off-by: Aggelos Tselios <aggelostselios777@gmail.com>
With memory sharing, tearing down the whole section will affect applications that wish to keep reading the data even after the server or the original application exited. Add a new operation instead to simply unmap a section from the current address space if needed, without touching other processes' memory view. Signed-off-by: Aggelos Tselios <aggelostselios777@gmail.com>
…teardown With reference counting, it is now possible to track whether a section can be safely unmapped from one application and remain mapped on the other, and this commit (hackishly) adds support for this. I wrote some units to test how well this works, it appears that memory sharing works but has some pitfalls still. Therefore we can now begin the first steps towards a proper disk driver. Signed-off-by: Aggelos Tselios <aggelostselios777@gmail.com>
tseli0s
added a commit
that referenced
this pull request
Aug 24, 2026
That previous hack in the other pull request is too ugly, but worse, it doesn't scale well (let's say I need to translate 10 handles, I'll need 10 messages for that). About time we implement this function actually. I believe pull request #11 should go away with this commit... Signed-off-by: Aggelos Tselios <aggelostselios777@gmail.com>
Owner
Author
|
Some commits in this pull request have been cherry picked into |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
These are some patches I wrote over the past few days to implement shared memory. From some basic tests I wrote, shared memory does seem to work now, though the current workings are very hackish and probably fragile. Debugging a double free at the moment, and I know some shortcomings that need to be addressed, but the general concept works.
We need shared memory for disk drivers and efficient software framebuffer blitting in general. Messages are quite limited by their nature, so sending a 1MB file, for example, will be way too slow and hackish to do with message payloads.