Comment by ww520 | Hacker News Reader

Comment by ww520 | Hacker News Reader

I browsed the source code a bit. Some interesting finds:

* The code is pretty simple and clean, clearly for educational purpose.

* There's no memory protection. All processes share the same memory space, along with the kernel.

* No virtual memory, nor page table.

* No notion of ring protection. The kernel and the processes run in the same ring.

* Max number of processes is 8. The process table is a fixed size array, of 8 entries.

* Context switch can be preemptive, driven by the clock interrupt.

* Process scheduling is round-robin, first in first run.

* Process priority is supported. Each priority has its own ready queue. All processes of the highest priority are run first in round-robin fashion, before running the next priority level.

* "Program" is just a function. All "programs" in the system have their starting functions hardcoded in the shell's cmdtab[], like cat, ping, etc. Executing ping is just creating a process with the address of the ping function.

* Loading a program from disk to run doesn't seem to be supported.

* The local file system is based on RAM block device. Accessing data on actual disk doesn't seem to be supported.

> Max number of processes is 8. The process table is a fixed size array, of 8 entries.

The max number of processes is the compile-time configuration knob NPROC in `config/Configuration`. The stock version of the file sets it to 100. Only if you remove that line do you hit the fallback in `include/process.h`:

    #ifndef NPROC
    #define NPROC           8
    #endif

Ah, good to know. I didn't go through the build process; just went by the define in the header file.

The caliber of persons we have here is amazing , you could tell all that by breezing through the source

Indeed! I'm always learning something new from the talented individuals on HN. Some of them are veritable quiet geniuses.

Quietish

LOL :P

Adding a memory paging system to Xinu is one of the projects for the Graduate level OS course based on this book.

That and scheduling. For many of us this is like a return to college, I imagine.

Might you or anyone else have a link to a graduate level course that covers adding these features to Xinu?

What you’re wanting is CS 503!

Edit: Purdue’s CS 503.

It was Purdue's CS503 course when I took it a number of years ago. I don't think there are any materials to be found online though. As I recall the professor outlined how x86 paging worked in one of the lectures and then we were given a link to the Intel manuals and told good luck. To keep things simple there were no disks in the system so the memory was paged over the network and they had a special lab setup to support the whole thing.

There is also an Operating systems course at Marquette University based around Xinu. That one is for undergrads though and based on a version targeted for an embedded MIPS processor so I don't think it covered paging but I never took that one so I'm not sure.

This sounds almost exactly like the feature set of most common microcontroller RTOSes. At least FreeRTOS and ThreadX have practically identical features except for the shell. Processes and process memory isolation are not supported on most controllers, so all you get is a single image containing both the operating system and the application. Fun fact: you even get to write the main function yourself and need to call the function that will start the OS explicitly from there.

A Microcontroller with real process isolation would be really nice, though. It could be used to safely contain whole classes of nasty bugs in the application software.

> A Microcontroller with real process isolation would be really nice, though. It could be used to safely contain whole classes of nasty bugs in the application software.

If this becomes a reality, programmers will become a lot less careful when writing the application software because of the additional level of protection. Google "risk compensation".

Yet I'd be more comfortable in the knowledge that e.g. the hardware control loop and the HCI are running in isolation on medical devices. Typically, the critical control code is kept small and is developed to higher standards than the UI code. Often, errors in the interface are seen as lesser risks, which allows that part of the code to be developed to lower standards, while at the same time being more complex. That is at least what I've seen done in practice.

Or you could read the books, which explain the design and implementation in detail. (-:

Would love to but I don't have access to the book. The website has very little on the design and feature of the OS.

The headlined page tells you that you do have access to the books. The second edition was published only 3 years ago, and is still in print from what I can tell.

It's not really the 2nd edition, given that there was a LinkSys edition with revisions from the first edition published in 2011.

The book is on Amazon, priced at $40 hardback. No "Look Inside".

https://www.amazon.com/Operating-System-Design-Approach-Seco...

In other words, it's like a self-contained multitasking DOS --- not unlike what you'd find on a PDA 2 decades ago, or perhaps a low-end portable media player today.

Edit: downvoters, care to explain...?

The vast majority of modern computing devices run with similar minimalist operating systems.

> No virtual memory

Are you sure about this? Xinu Timeline (3-rd paragraph on the site) states:

1988-90 - Xinu ported to 32-bit mode x86 architecture; virtual memory support added.

Disclaimer: I haven't read the code.

I'm fuzzy on the history, but I believe that modern Xinu is actually a complete rewrite since sometime in the early 2000s (the linked page says "ports the code to the x86 architecture " again in 2010-2011).

In 2014 Dr. Comer had taped to his office door a sheet of project ideas for grad students, one of them was adding virtual memory support to Xinu.

I'm not sure what it's referring to. I just went by the code for i386.

I just checked again. Searched for the "CR0" or "CR3" register, which would be used to set up the protected mode and virtual memory for the i386 CPU. Didn't find anything. Searched for "virtual" and found no match. Searched for "paging" and found no match. The process table entry only had the address to the starting function and the stack addresses for context switch; there's no process memory information. The process creation process didn't touch anything memory related, except setting up the stack.

I don't believe virtual memory is supported based on what's in the code.

I totally believe you, but this is not the feature set described by the TOC of the book[0], which appears to include virtual memory management and a file system among much else.

[0] https://xinu.cs.purdue.edu/cont.html

Reply on news.ycombinator.com