Wednesday, December 5, 2007
Prima Design Decisions: Regions
As you may have noticed from earlier articles, I am somewhat compulsive about portability. Of course, this can be difficult to achieve in a kernel. The kernel is where you get your hands dirty. It is where details such as pages, bits and special registers must all be dealt with.
Fortunately, a microkernel-like design, if not a true microkernel, allows a significant advantage because we can partition our code so that only the kernel itself is aware of these details. The rest of the operating system can access these dirty bits and bytes through abstractions. That's where regions come in.
For Prima, I've decided to model core as regions. Each region has a property of size, virtual start address, and granularity. We can allocate and dispose of regions, and resize them. We will also be able to assign some sort of signaling to each regions so that whenever some sort of need arises to signal a process or thread, the kernel can do so. What we get back is an identifier or "handle" that we can pass to the kernel to allow it to operate on that piece of memory.
There will also be system calls that allow you to transfer data into and out of any region. This is to allow me to avoid one of the costly operations seen in some microkernels, the copying of data in to and/or out of messages. I would much rather hand off a region handle and virtual address to read from or write to in a message than copy the data itself into and out of the message.
Of course, the devil is in the details, and I'm not sure of all those details. But, the design makes sense from an architecture standpoint, regardless of whether or not the design becomes a hypevisor or just a typical, more mundane microkernel.
Of course, this is just one of many design decisions that must be made during the design of an operating system, so don't be surprised if you see something detailed later on that doesn't entirely agree with this. Any complex software architecture will need to be adjusted here and there as the whole design solidifies.
Expect to see some aspect of regions in the next proof of concept release.
Fortunately, a microkernel-like design, if not a true microkernel, allows a significant advantage because we can partition our code so that only the kernel itself is aware of these details. The rest of the operating system can access these dirty bits and bytes through abstractions. That's where regions come in.
For Prima, I've decided to model core as regions. Each region has a property of size, virtual start address, and granularity. We can allocate and dispose of regions, and resize them. We will also be able to assign some sort of signaling to each regions so that whenever some sort of need arises to signal a process or thread, the kernel can do so. What we get back is an identifier or "handle" that we can pass to the kernel to allow it to operate on that piece of memory.
There will also be system calls that allow you to transfer data into and out of any region. This is to allow me to avoid one of the costly operations seen in some microkernels, the copying of data in to and/or out of messages. I would much rather hand off a region handle and virtual address to read from or write to in a message than copy the data itself into and out of the message.
Of course, the devil is in the details, and I'm not sure of all those details. But, the design makes sense from an architecture standpoint, regardless of whether or not the design becomes a hypevisor or just a typical, more mundane microkernel.
Of course, this is just one of many design decisions that must be made during the design of an operating system, so don't be surprised if you see something detailed later on that doesn't entirely agree with this. Any complex software architecture will need to be adjusted here and there as the whole design solidifies.
Expect to see some aspect of regions in the next proof of concept release.
# posted by Pat Villani @ 5:36 AM 
Subscribe to Posts [Atom]
Copyright Pasquale J. Villani