Resource Magement #127

maxtyson123 · 2025-09-02T06:06:24Z

Here's the base write-up. Once settled on the design, I will go through and mix this in with the files and IPC.

closes #113

06_Userspace/06_Resource_Management.md

DeanoBurrito · 2025-09-15T06:53:24Z

06_Userspace/06_Resource_Management.md

+
+## Resource Abstractation
+When talking about _resources_, we need a way to distinguish between the different types that the kernel may expect to provide to userspace. Each resource behaves differently internally, but from the view of the userspace process everyting should be acessable from the same set of syscalls. In order to achive this, we define an enum of resource types to allow the kernel to tag each resource with it's category. This way when a system call is made, the kernel knows how to dispatch the request.
+```


Pandoc (used for generating the pdf) doesnt like changing between text and code blocks within an empty line in between. Same goes for headings (# Per Process Resource Table and friends), can you update all of these?

06_Userspace/06_Resource_Management.md

dreamos82 · 2025-11-11T17:16:11Z

06_Userspace/06_Resource_Management.md

+
+## Resource Abstractation
+
+When talking about _resources_, we need a way to distinguish between the different types that the kernel may expect to provide to userspace. Each resource behaves differently internally, but from the view of the userspace process, everything should be accessible from the same set of syscalls. In order to achieve this, we define an enum of resource types to allow the kernel to tag each resource with its category. This way, when a system call is made, the kernel knows how to dispatch the request.


Even if in the example is an enum, I don't think that it has to be strictly it.
The sentence is kind of assuming and telling it, I think that it can be made more generic.

Something like: In order to achieve this we need to define a set of resource types to allow the kernel to tag each resources, for example we can use an enum... etc.

dreamos82 · 2025-11-11T17:17:56Z

06_Userspace/06_Resource_Management.md

+
+When talking about _resources_, we need a way to distinguish between the different types that the kernel may expect to provide to userspace. Each resource behaves differently internally, but from the view of the userspace process, everything should be accessible from the same set of syscalls. In order to achieve this, we define an enum of resource types to allow the kernel to tag each resource with its category. This way, when a system call is made, the kernel knows how to dispatch the request.
+
+```


Ah, please add the programming language, to have it rendered correctly by pandoc, and markdown.
So it will be something like:

```c

(do it everywhere in the code on your pr pls! :D)

dreamos82 · 2025-11-11T17:22:27Z

06_Userspace/06_Resource_Management.md

+} process_t;
+```
+
+Now each process has a resource table that is a map of integers, called _handles_, to the kernel resource objects. A handle is simply an identifier returned by the kernel when opening a resource that is later used by the user to inform what resource the operation should be performed upon. This indirection is important because we do not want to expose any kernel pointers directly to a userspace process. Even if they cannot be used there, passing them could still create security or stability risks. This way, the resource structure is not exposed to userspace. Because of this, the same handle number in different processes can refer to different resources. For example, in Unix, handles `0`, `1`, and `2` refer to stdio for each process and are called "file descriptors". 


stdio and stderr? :D

dreamos82 · 2025-11-11T19:40:37Z

06_Userspace/06_Resource_Management.md

+2. While the handle is valid, the process can perform operations such as `read_resource` or `write_resource`.
+3. Finally, when the process has finished using the resource, it calls `close_resource`, allowing the kernel to free any associated state.
+
+Typically, a process should `close()` a resource once it is done using it. However, that is not always the case, as processes may exit without cleaning up properly, and thus it is up to the kernel to ensure resources aren't leaked. This could look like a loop through the process's resource table, calling `close_resource(process, handle);` for each open resource and letting the resource-specific `close()` function handle the work.  


I would say the first close() in this sentence, should be just italic, without parenthesis, since it refers to the one above that is close_resource, it could be confusing,.

dreamos82 · 2025-11-11T19:42:49Z

06_Userspace/06_Resource_Management.md

+
+Here, `funcs` is the dispatch table that tells the kernel how to perform each operation for each resource. With this, each function pointer can be set differently depending on whether the resource is a file, IPC endpoint, or something else. Operations are defined to be blocking by default, meaning that if a resource is not ready (for example, no data to read), the process is suspended until the operation can complete. Each resource type can override these generic operations to provide behavior specific to that resource.
+
+It has been left as an exercise to the reader to decide on how they want to handle extending this design for extra resource-specific functionality (ie, renaming a file). A simpler design may be to just add more syscalls to handle this; however, this means the ABI grows as your kernel manages more resources.


functionality of functionalities?

comma just after ie? Is that correct (I ask because I don´t know if in English is correct)

dreamos82 · 2025-11-11T19:47:59Z

06_Userspace/06_Resource_Management.md

+Another thing left as an exercise to the user is to decide their method of copying data between userspace and the kernel.
+One option is to use the userspace provided buffers, which is efficient due to a single copy but does require sanitization of pointers and lengths to ensure safety. Some things to consider are other threads in the same address space modifying memory at the same address. Another option is to copy into a kernel buffer first, which simplifies the sanitization but has the added overhead and loss of performance. 
+
+With using the user buffers, it's not necessarily a single copy, and you may be able to operate directly on the buffer (in which case it's zero-copy). Although, this can be dangerous as another user thread can write to, unmap, or remap the buffer while the kernel is operating on it. Holding a lock over the address space for that process throughout the entire duration of the resource operation is impractical, so the kernel must instead rely on fault handling. By faulting when the process tries to access the memory that the kernel is working with, it allows this behaviour to e caught and the kernel can try to abort or retry the operation safely. 


At end of sentence: to e caught (missing b)

dreamos82 · 2025-11-11T19:48:21Z

08_VirtualFileSystem/02_VirtualFileSystem.md

 * No extra features like permissions, uid and gid (although we are going to add those fields, they will not be used).
 * The path length will be limited.

+This VFS is built on top of the previously defined resource API (see Resource Management). The VFS creates a file-specific `resource_t` for each open file and returns a handle that is then used with the resource manager's generic `read`, `write`, and `close` functions that will perform the proper handle-to-resource lookup and call our VFS functions.


Add a Link to the resource management chapter.

maybe handle-to-resource make it italic?

dreamos82 · 2025-11-11T19:53:38Z

08_VirtualFileSystem/02_VirtualFileSystem.md

 ```

-The fildes argument is the VFS file descriptor id, it will be searched in the opened files list (using an array it will be found at `vfs_opened_files[fildes]`) and if found it should first call the fs driver function to close a file (if present), emptying all data structures associated to that file descriptor (i.e. if there are data on pipes or FIFO they should be discarded) and then doing the same with all the vfs resources, finally it will mark this position as available again. We have only one problem how to mark a file descriptor available using an array? One idea can be to use -1 as `fs_file_id` to identify a position that is marked as available (so we will need to set them to -1 when the vfs is initialized).
+The `res` argument is the file resource to be closed, it will be called from the `close_resource(...)` of the kernel's resource manager. It should first call the fs driver function to close a file (if present), emptying all data structures associated to that file descriptor (i.e. if there are data on pipes or FIFO they should be discarded) and then doing the same with all the vfs resources, finally it will mark this handle as available again. 


should we specify somewhere that these are not the standard functions ? (since the parameters are different?)

dreamos82 · 2025-11-11T19:54:29Z

08_VirtualFileSystem/02_VirtualFileSystem.md

+Where the parameters are the opened file resource (`res`) the buffer we want to read into (`buf`), and the number of bytes (`nbytes`) we want to read.

-The read function will return the number of bytes read, and in case of failure -1. Like all other vfs functions, what the read will do is search for the file descriptor with id `fildes`, and if it exists call the fs driver function to read data from an opened file and fill the `buf` buffer.
+The read function will return the number of bytes read, and in case of failure -1. Like all other vfs functions, what the read will acutally do is verify the resource and then call the fs driver function to read data from an opened file and fill the `buf` buffer.


dreamos82 · 2025-11-11T19:57:06Z

08_VirtualFileSystem/02_VirtualFileSystem.md

-        return bytes_read;
-    }
-    return -1;
+ssize_t read(resource_t* res, void *buf, size_t nbytes) {


Ok so this is read, and above we are using read_resource? And before we use again read. Let's decide on a name :D

dreamos82

see previous comments

maxtyson123 added 2 commits September 2, 2025 15:47

Add resource management documentation

6ab39f1

Enhance Resource Management documentation

be639e6

dreamos82 reviewed Sep 4, 2025

View reviewed changes

maxtyson123 added 2 commits September 5, 2025 18:24

Fix based on feedback

80fbbb8

Small fixes

8cfe208

DeanoBurrito requested changes Sep 15, 2025

View reviewed changes

maxtyson123 added 7 commits September 21, 2025 16:31

Spelling

fe03880

Requested Content Changes

f05bffe

Proper Spacing

24aa63e

Merge branch 'dreamportdev:master' into master

8f7206b

Add register/remove functions

edc8488

DRAFT: VFS use resource calls

008fdbc

Clarify ambiguous VFS resource statement

1f9f8bd

dreamos82 approved these changes Nov 11, 2025

View reviewed changes

dreamos82 requested changes Nov 11, 2025

View reviewed changes


		## Resource Abstractation

		When talking about _resources_, we need a way to distinguish between the different types that the kernel may expect to provide to userspace. Each resource behaves differently internally, but from the view of the userspace process, everything should be accessible from the same set of syscalls. In order to achieve this, we define an enum of resource types to allow the kernel to tag each resource with its category. This way, when a system call is made, the kernel knows how to dispatch the request.


		Here, `funcs` is the dispatch table that tells the kernel how to perform each operation for each resource. With this, each function pointer can be set differently depending on whether the resource is a file, IPC endpoint, or something else. Operations are defined to be blocking by default, meaning that if a resource is not ready (for example, no data to read), the process is suspended until the operation can complete. Each resource type can override these generic operations to provide behavior specific to that resource.

		It has been left as an exercise to the reader to decide on how they want to handle extending this design for extra resource-specific functionality (ie, renaming a file). A simpler design may be to just add more syscalls to handle this; however, this means the ABI grows as your kernel manages more resources.

Uh oh!

Resource Magement #127

Are you sure you want to change the base?

Resource Magement #127

Conversation

maxtyson123 commented Sep 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dreamos82 left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

maxtyson123 commented Sep 2, 2025 •

edited

Loading