Hello,
I know that each process has a memory segment for the OS space as illustrated on this image. But what kernel structures reside in this memory area?
https://stackoverflow.com/questions/951 ... rogramming
what part of the OS resides in each process address space?
-
- Member
- Posts: 5568
- Joined: Mon Mar 25, 2013 7:01 pm
Re: what part of the OS resides in each process address spac
All of them, usually.
Re: what part of the OS resides in each process address spac
Is this sudden invasion of new posters a sign of osdevelopers, generated by AI? Hopefully, they will be less plastic, than AI generated girls.
An address space owner is a process, it owns it in its entirety, as a concept, with that part, where the kernel resides incl. I like this view, it's simple and clear. The kernel, thus, is a kind of library, loaded into the process AS. There is a public part of the kernel, which is mapped the same for all processes and private one, with per process mapping. The former is for objects that should point to the same phisically content from any thread (every thread belongs to some process and runs in the process' address space), say kernel code, the latter is for things, that should point to the private parts of the process when it runs priveleged, kernel code. I believe, threads' kernel mode stacks are from this category. Or maps themselves*. For the public part some address A in the "virtual" AS points to the same thing both class wise and instance wise, for the private, - normally same only class wise. So, address A for process P1 would be say stack location at system/physical address S1 and for process P2, it also would be a stack location, but the mapping would be to the physical address S2.
* - for every address space, every process, that is, you would need to build page tables for the entire mapping, both user mode accessible and kernel mode. It can't reside in the user mode accessible part, otherwise it would be a huge security risk. On the other hand, the mapping would consume a significant amount of address range, so it wouldn't be wise to make it into the public part, allocating some part of it for every new process, it's the way for denial of service. apparently, that you need to introduce a range in your layout, classified to be used as a container for maps. It would start at the same address for every AS, but will point to different physical locations, each for every process. hope, you get the idea from my messy explanation.
An address space owner is a process, it owns it in its entirety, as a concept, with that part, where the kernel resides incl. I like this view, it's simple and clear. The kernel, thus, is a kind of library, loaded into the process AS. There is a public part of the kernel, which is mapped the same for all processes and private one, with per process mapping. The former is for objects that should point to the same phisically content from any thread (every thread belongs to some process and runs in the process' address space), say kernel code, the latter is for things, that should point to the private parts of the process when it runs priveleged, kernel code. I believe, threads' kernel mode stacks are from this category. Or maps themselves*. For the public part some address A in the "virtual" AS points to the same thing both class wise and instance wise, for the private, - normally same only class wise. So, address A for process P1 would be say stack location at system/physical address S1 and for process P2, it also would be a stack location, but the mapping would be to the physical address S2.
* - for every address space, every process, that is, you would need to build page tables for the entire mapping, both user mode accessible and kernel mode. It can't reside in the user mode accessible part, otherwise it would be a huge security risk. On the other hand, the mapping would consume a significant amount of address range, so it wouldn't be wise to make it into the public part, allocating some part of it for every new process, it's the way for denial of service. apparently, that you need to introduce a range in your layout, classified to be used as a container for maps. It would start at the same address for every AS, but will point to different physical locations, each for every process. hope, you get the idea from my messy explanation.
Re: what part of the OS resides in each process address spac
At least in my design, the largest part of the shared kernel are the cached filesystem content (both sectors and files). That's why my new design has moved filesystem services to server processes where these things can be kept in their own process spaces and not in the address space of every process. This also makes it possible to cache up to 2G of filesystem metadata per partition. In this new design, I don't map cache sectors in the address space, rather keep them as physical addresses only mapping them when necessary in user space. This is the major issue for creating a good 32-bit kernel that gives applications as much address space as possible while still using as much as possible of physical memory to cache disc sectors & filesystem metadata. Particularly since typical modern machines have a lot more than 4G of RAM.
Keeping the kernel stack in private part of the process is interesting. I don't do this currently, and it would be a bit problematic since it's mapped to a GDT selector too. Maybe it could be mapped to the LDT? I don't support 1000s of threads, mostly because every thread consume three GDT selectors.
I have kernel threads too, which are not connected with a usermode process. These typically run in the system process that is created at initialization time, but they can also create their own kernel mode process.
Keeping the kernel stack in private part of the process is interesting. I don't do this currently, and it would be a bit problematic since it's mapped to a GDT selector too. Maybe it could be mapped to the LDT? I don't support 1000s of threads, mostly because every thread consume three GDT selectors.
I have kernel threads too, which are not connected with a usermode process. These typically run in the system process that is created at initialization time, but they can also create their own kernel mode process.
Re: what part of the OS resides in each process address spac
The timing is explained by the fact that I became a mod yesterday and decided to clear the mod queue. And there was like half a year of backlog. In the end, I let almost everyone through, except one curious fellow who kept asking for people that know about Windows reverse engineering. Something about the posts were sus, as was the fact that they were repeated thrice without any change. It seemed like it was either spam or an invitation to criminal enterprise.zaval wrote:Is this sudden invasion of new posters a sign of osdevelopers, generated by AI?
Are these people AI? We will see, but if someone managed to create generative AI that actually produces halfway decent OSdev content, I call that a win.
Carpe diem!
-
- Member
- Posts: 5568
- Joined: Mon Mar 25, 2013 7:01 pm
Re: what part of the OS resides in each process address spac
One of them was, but they were also a spambot so I banned them.nullplan wrote:Are these people AI?
Re: what part of the OS resides in each process address space?
Code: Select all
except one curious fellow who kept asking for people that know about Windows reverse engineering. Something about the posts were sus,
I thought that windows was very slow in processing until I bought an NVMe, then I discovered it was just that Microsoft likes to bloat everything so that we always have to buy new hardware.
Re: what part of the OS resides in each process address space?
No, that was some unapproved rando. That's why the posts were in the mod queue in the first place. And your questions typically don't make me wonder about legal issues, either.
Price of progress, I guess. I once heard someone state "I love Java. Not the language, and also not the JVM, but because Java apps are all so bloated, people keep demanding more and more RAM, and that's why RAM prices are down."
Carpe diem!
Re: what part of the OS resides in each process address space?
Never thought of that, actually that's so clever.
Though Windows can decide to use less than 500 Mb if it wants too but the economy should keep going haha
Though Windows can decide to use less than 500 Mb if it wants too but the economy should keep going haha