Persistence makes you capable
During my research of operating systems kernels, I got side tracked towards security mechanisms in operating systems and their kernels. Obviously, I'd heard of the usual 2:
- Access Control Lists (ACL's), and
- Capabilities.
ACL's are used in most OSes due to being easy to implement, and I had no idea how to implement capabilities, so I thought I'd try and research them. Seems they're incredibly hard to understand unless you're one of these research type people who spend their days writing in bizarre mathematical notation and dream in Z!
Whilst on IRC, I did go into the #erights channel on Freenode and talk to the guys there who did essentially say that an object-oriented OS is basically a capability OS. They were saying that by holding onto a capability, a process has the right to access whatever that capability points to.
Now, from what I understand, the kernels like EROS and Coyotos define a set of objects (like a class in OOP) that are defined in the kernel. Each of these objects have a bunch of capabilities associated with them, these capabilities are like the method calls of an OOP language so that other programs can call them. So, these capabilities are essentially syscalls into the kernel via Inter-Process Communication (IPC) mechanisms.
Another part of my research into other security mechanisms lead me to HiStar, which is a kernel based on Π-Calculus, no me neither! This stuff is even harder to understand than the capability papers, maybe I should try reading them for longer rather than skimming?
Persistence
Another area of capability based OSes is that they tend to use persistence. This it seems, is due to:
- The capabilities being managed by the kernel, and
- Not knowing what configuration capabilities should be in when the machine is rebooted.
So, how was the HURD going to do it using user-space capabilities?
Now, the idea of orthogonal persistence is a fine one:
- You don't have to worry about saving any documents, images, etc. whilst using the OS as the checkpointing mechanism will save your data at regular intervals, i.e. at, say every 5 mins, the system will take a snapshot of the current state of the OS and save this to disk.
- If somebody pulls out the mains cable by accident (or to turn on a hoover), you won't have lost everything you've been working on (you might have lost something between checkpoints though), so when you restart the machine, everything (mostly) will still be present in your session.
Persistence basically maps RAM onto disk. RAM is managed in page sized chunks (usually 4KB), so each page in RAM has a page on disk. When a program opens a file from disk, the OS will just memory map (mmap) the page from disk into RAM, now if the file is small (say, less than a page in size) and you also have quite a few small files open at any one time, you are essentially not utilising RAM efficiently.
Conclusion
- Nobody knows how an OS based on capabilities is to present itself to the user as it's never really been done. Most capability based OSes are research projects and tend to get shelved when the research has completed and it hardly ever gets released to the public.
- Most of it is research and can be found in (sometimes) hard to read papers.
- Placing capabilities in the kernel seems to tie the filesystem to the kernel as well, this goes against the concept of a μ-kernel.
- With persistence, small files (less than the page size) can cause memory to just be eaten up really quickly.
I've already set myself quite a task in using Ada as the implementation language for an OS kernel, so I think that rather than try to cram in all these extra features, I should concentrate on just getting a portable μ-kernel developed
Reply #2 on : Mon December 10, 2007, 22:14:59
Reply #1 on : Sun December 02, 2007, 21:47:45
Write a comment
- Required fields are marked with *.
Reply #3 on : Tue December 11, 2007, 20:37:02