Rephrasing:
Meaning that a bug in the kernel space can cause a BSOD.
A bug in user space can crash the process, but not cause a BSOD.
So why is it put to put it in user space?
Rephrasing:
Meaning that a bug in the kernel space can cause a BSOD.
A bug in user space can crash the process, but not cause a BSOD.
So why is it put to put it in user space?
Originally Posted by Adak
The reason that a bug in user space only crashes the process is because of the fact that memory management is done in kernel space. If all memory management was done in user space, a single bad application could trash the entire system.
Other reasons memory management is done in kernel space?
- Page sharing. Two processes that load the same library can map in the same pages which saves on total memory usage.
- Kernel memory. The kernel needs memory too, but it doesn't run in user space.
- Security. If any process can read the memory contents of another process, this presents security concerns.
- Disk caching.
bit∙hub [bit-huhb] n. A source and destination for information.
Well, I'm not sure I buy this.
We agree that the memory manage must not contain bugs. If it crashes, it brings down the system with it, whether in user space or kernel space.
This can be done in user space too, AFAIK. I don't see why not?- Page sharing. Two processes that load the same library can map in the same pages which saves on total memory usage.
This sounds like the biggest problem. Unless some upcalls are possible, but they're typically considered a bad idea... hmmm.- Kernel memory. The kernel needs memory too, but it doesn't run in user space.
The OS controls the processes, so it could deny all read and writes to any portion of the memory manager's memory.- Security. If any process can read the memory contents of another process, this presents security concerns.
Besides, all other processes use virtual memory while the memory manage deals with physical memory.
I don't see the security issue there, really.
Why is this not possible in user mode?- Disk caching.
Meh. Maybe I should be asking if there is any good reason for doing memory management fully in user space.
At least some of it can be done in user space.
In order to actually do disk caching, you would need to write what you want there and restore it to RAM later. I'm pretty sure it isn't much more complicated than that but it's all done by a device driver. How or why would you want to run that in userland, too?
Perhaps you should have just asked "possible to get rid of the 'lands'?"... Seriously, why?
Oh yes, we want to be doing that, it was such a good idea 20 years ago.
The usual justifications are either performance (minimising overhead) or making life easier for the programmer (enabling simpler methods rather than complex APIs with their pesky error checking). Problem is, those benefits usually come at the expense of reliability - programmers have demonstrated convincingly that they cannot be trusted to ensure system integrity if they have access to system resources from userland code.
Indeed. In the days of MS-DOS and early versions of windows that ran on top of DOS (up to windows version 3.11 IIRC) all memory on the machine was accessible from user-mode code. One notable characteristic of those systems is that they were unable to protect themselves from actions of running programs. Quite a few programs were written, accidentally or deliberately, that could easily crash the system, overwrite memory being used by other programs, and also do things like reformat hard drives without confirmation.
Protected mode processors, memory management units, kernel mode, etc were designed to prevent user-land processes from having unfettered access to system resources that might be used by other processes (whether physical or virtual). One of the arts of modern operating system design is selecting what actions are permitted in "user mode" versus those that are permitted in "kernel mode".
So, in answer to the original question, yes it would be possible to design an operating system that places system memory management into user space. That would run completely at odds with the way things have developed over the last 20 years or so (the trends have been to increasingly prevent user programs from managing system memory). It would probably be easier to tailor your own operating system, rather than attempting to modify a modern operating system to allow it, as most modern operating systems are specifically designed to do the opposite.
Last edited by grumpy; 05-04-2011 at 02:21 AM.
