I wrote the following article for university. It tries to explain the difference between three kernel types in such a way that less-computer savvy people should understand it. I had a 1500 word limitation, so detailed elaborations were out of the question. "In this article, I will try to make the 'microkernel vs. monolithic kernel' debate more accessible and understandable for laymen. I will explain the purpose of a kernel, after which I will detail the differences between the two competing designs. Finally, I will introduce the hybrid design, which aims to combine the two. In the conclusion, I will argue that this hybrid design is the most common kernel type in the world of personal computers today." Because of the limitations, this article contains little news for most of you. Still, I thought I'd share.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-07-08
I don't think the global segment limitation would have been as much of a problem as the address space limitation. A standard segmentation layout for a 32-bit address space has 16 segments of 256MB each. This is virtual memory, of course, not physical memory. Typically the kernel would only get one segment mapped into each process' address space when running in usermode and a few more (4 is common) when running in kernelmode. If the idea was to put different drivers or subsystems in different segments, then this wasn't nearly enough to be useful.
With 64-bit addressing, we now have room for nearly 70 billion segments (up from 16, remember). Obviously this has a tremendous impact on the feasibility of dividing kernel components by giving them their own segments. As long as we look out for malicious or buggy code, we can hand out segments to whatever kernel modules get loaded without thinking twice about running out.
Member since:2006-01-02
Member since:2005-08-22
With x86 segmentation, remember, it's 16:32 for the pointers. There are a few unusable bits in the segment part, but the entire offset part is usable. You can make every segment 4 GB if you want, as long as you set up matching page tables to make it work. Segments can be whatever size you want, down to the byte up to 4 MB. Past that point, you get control in 4KB steps.
Every process would need at least 2 segments - one for code and one for data. You can't mix both in one segment descriptor. You'd probably want one more segment for read only data.
When I tried thinking about how to use segments, I envisioned it as loading each shared library into its own set of segments, managed to be identically numbered across apps. That way, you'd have a lot less relocations as you'd only need to do the segment part - the offset would be known at link time. No additional relocations would be necessary when a second app decided to use the library. Of course, this scheme would fall apart if you tried running a gnome app and a kde app at the same time due to their insane amount of dependencies.
Member since:
2005-08-22
The bottom line is that if the powers that be wanted us to have operating systems that have strong isolation between system components, then one of the major hardware platform vendors would have implemented segment-granular hardware MMUs many years ago.
That's what the 386 was designed for. The segmentation support offered much better memory protection than paging. No one chose to use the features, mainly because people tired of dealing with the weird segment:offset addressing scheme on the 8086 were too afraid to give the 386's improved version of it a chance. As far as I know, Watcom is the only compiler that can do the necessary 48 bit pointers.
Also, the 386 design was limited to 8192 segments (or that many global segments, plus an equal number of process local ones, I forget). If you were able to use a few more bits of the 16 bit selectors, I think it would've been great, but with the 8k limit, it felt like you'd have to be rather aware of when you were allocating new segments in a large program.