OSDev.org

Dear Friends,

I envision an OS almost like a library.
It may consists of:
- a collection of procedures to support OS functionalities.
- a collection of procedures to access hardware synchronously
- a collection of IRQ service procedures to access hardware asynchronously

And only two running processes
- idle task (a HLT loop)
- shell task to wait for user command in a loop

Is it possible to implement such an OS? Any example OS?(if we have such)
What could be the disadvantages in this approach? (like disk access suffers due to lack of a system process taking care of caching of disk blocks)
What are other system specific processes that are almost mandatory except idle and shell?

Sincerely,
Srinivas Nayak

snayak wrote:Any example OS?

DOS.

You just described every OS.

The purpose of the OS is to be a common framework for applications to run on top of. The purpose of a library is to be a common framework for applications to run on top of.

If you want a more explicit example, for instance, Windows NT is comprised pretty much entirely of a whole bundle of DLLs. Dynamic Link Libraries. It's in the name.

The "only two running processes" narrows it down quite a bit. DOS is the first operating system I can think of that comes anywhere near meeting that particular requirement.

I only paid attention to the two thread thing because you guys were picking up on it.

So... they're looking at an operating system that doesn't run applications? Ooooooookay.

EDIT: I'm re-reading what you said and I see that you just mean OS tasks specifically. And technically, you could have zero OS tasks.

If you just run a user application at startup, that can be the only thing running on the machine even though it may make calls to the OS 'library functions'.

EG: if you set up your autoexec in dos to run some program immediately at boot.

Aside from the aforementioned MS-DOS (and other monotasking systems of this sort, as they do represent a kind of extreme case for what you describe), you might want to look into the subject of Exokernel systems, which are technically very similar to hypervisors but represent a different use pattern. While I a not certain, it sounds like you may be looking for something along those lines.

The original research paper on the idea can be found on CiteSeer, among other places.

Oh, and just to make the issue clear, in most operating systems, especially those of the Unix family, the shell and other user interfaces are not system processes. Windows and MacOS are the primary exceptions, of course (well, I'm not sure if MacOS is either, come to think of it; it was true for pre-OS X Mac systems, but since the Darwin kernel is based on a blend of Mach and FreeBSD, that may have changed any time in the past 20 years. While the GUI is far more closely bound to the OS than in other Unices, it probably still runs in userland).

Many thanks.

[Very very sorry for late reply. I didn't notice to check Notify me option...and so I was not notified of the replies... Now did.]

DOS is fine...
However I liked the exokernel approach given in the paper cited.
In Tenanbaum's book, he says eCos is such an OS.

To be honest, my question was little odd in constraining things a bit. By two thread actually I wanted to say, no system processes, that is, no active or running processes from OS or kernel should be present. If you see, in Linux, we have a lot of kernel threads running... that i wanted to avoid. The first three points which I said, actually describes all OSs. But my intention was to see an OS where only applications are active, that is, run as process, but OS is simply remains as passive one and almost dumb like a library...

Hope, I described my intention clearly...
But still, if I have constrained a bit more, kindly suggest or correct.

Regarding "disk access suffers due to lack of a system process taking care of caching of disk blocks"... Generally Linux or other OSs have a thread running to serve disk access...this process or thread's duty is to receive access request from user processes, serialize them, asynchronously access disk, cache the data, deliver the requested data to user process... I wanted this NOT to be there...no such process representing OS...true that without serializing disk requests and caching disk gets rotten faster, but just incase and OS are there with such an approach...

Sincerely,
Srinivas Nayak

snayak wrote:To be honest, my question was little odd in constraining things a bit. By two thread actually I wanted to say, no system processes, that is, no active or running processes from OS or kernel should be present. If you see, in Linux, we have a lot of kernel threads running... that i wanted to avoid. The first three points which I said, actually describes all OSs. But my intention was to see an OS where only applications are active, that is, run as process, but OS is simply remains as passive one and almost dumb like a library...

Well this is basically how Ghost Kernel. The kernel has no threads and acts only as a dispatcher/kind of library and maintains stuff.

Well, here's the thing: different use cases are better served by different operating system designs. Exokernel designs, like the similar containerizing hypervisor, tend to work best in three scenarios: one, dedicated servers with only one or a small number of related services which can take advantage of a highly optimized I/O library specific to that service (e.g., a database server, where there is no general-purpose file system, just the DBMS, or an HTTP server which serves a fixed number of pages and can cache most of the pages); cycle servers where most of the operations are compute-bound, and most I/O is network traffic through to a constrained and highly optimized channel (which is sort of an instance of the first use case, though it has some unique characteristics); and systems running a small set of disconnected applications with little or no overlap in the use of I/O services (e.g., one program uses one disk, the other uses a different one).

Exokernels tend to have problems when the same peripheral is being used by several virtual machines at the same time for different purposes; you end up with a case where you either have to

• use a general-purpose library for all the different applications, which would defeat most of the purpose of having a library driver,
• coordinate the libraries' access to the peripheral, which requires IPC that may or may not incur multiple system-level context switches, or
• have a higher-level abstract driver that queues the library drivers' access to the contended peripheral (which not only is exactly the kind of abstraction exokernels are meant to avoid, but also could just as easily be used in an conventional OS with a list of multiple loadable drivers - which is in fact a design I am considering myself).

I should explain that my own design call for a stripped-down containerizing hypervisor - I was even thinking of having it be a completely separate system from the client virtual machines, though I am reconsidering it given my recent reading of the Synthesis white paper's description of the S-machine concept - which manages several subordinate paravirtualized systems, each of which would have some services of their own but can share other services either as libraries or as dedicated virtual machines behaving as internal servers. The root system would focus on multiplexing the virtual machines, but would have some facilities for IPC and service sharing as well. Each Kether VM would only have those services it actually provides itself, though other client operating systems running under the root hypervisor could, of course, be full systems (if you wanted to share the system with, for example, a Windows VM). Shared resources, such as disks, would have a special VM acting as monitors (in the of being a gatekeeper to the resource).

I imagine the security of such a design to be very poor. It relies on every process using the same library; what's to stop a malicious application from accessing the hardware directly, without whatever protection the library has put in place?

onlyonemac wrote:I imagine the security of such a design to be very poor. It relies on every process using the same library; what's to stop a malicious application from accessing the hardware directly, without whatever protection the library has put in place?

I assume that this is regarding the general exokernel concept, not my ex tempore description of my own ideas (see footnote). With that assumption in mind: very good question, I don't know what security approaches have been used with exokernels in the past, so I can't really say. AFAICT, the main focus of exokernel development has been raw throughput, not security.

1] My current idea - which, just to be clear, is nothing remotely similar to an exokernel, despite the use of paravirtualized VMs for each application - is that the root system would assign access to a given resource exclusively to the monitor VM, which in turn would manage the code-generation templates to be applied to the resource. If a specific driver optimization is needed, the monitoring VM's code generator would provide it.

In an exokernel, the library doesn't provide any protection- that's still the kernel's job. The idea is to provide protection at a lower level rather than baking that protection into the abstractions (and thus limiting userspace to only those abstractions).

For example, instead of implementing the entire file system, the kernel only needs to understand inodes and file permissions to determine whether userspace can read or write particular disk blocks. MIT's exokernel research project did this with a BPF-like in-kernel bytecode used to define functions from inode content to allocated blocks, so even that code could be untrusted.

Similar things can be done with virtual memory, networking, and scheduling. It takes some thought and some clever tricks to make it work securely, but it's been done. The MIT papers are pretty interesting and well-written if you want more details.

Ah, thank you, Rusky. As I said, I didn't know what designs had been put forth for that in the past.

What about making a Single address space operating system that implements system calls as regular function calls instead of using interrupts or special system call instructions? I am going to make my own OS something like this. I have studied TempleOS code a little bit to see how to do stuff. It's public domain, so hopefully the code can be used in any way you want.

The downside with a SASOS could be lack of memory protection, unless you use a memory-safe programming language for application software.

obfusc8or wrote:The downside with a SASOS could be lack of memory protection, unless you use a memory-safe programming language for application software.

Unless you use a memory-safe programming language for system software.