* 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.
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`:
#define NPROC 8
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.
Edit: Purdue’s CS 503.
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".
It's not really the 2nd edition, given that there was a LinkSys edition with revisions from the first edition published in 2011.
Edit: downvoters, care to explain...?
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 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.
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.
On the wikipedia page for the game , it says that it uses Pinball 2000 hardware. And on the wikipedia page for Pinball 2000 , it uses Xina (Xina is not Apple) and not Xinu. Is there another variant of the OS?
The "Pinball 2000 hardware" setup was an ATX motherboard running a MediaGX CPU (x86 clone, it lives on as AMD Geode). It also had a custom PCI card for storage and sound DSP, and a secondary board connected by parallel port for driving lamps and solenoids.
XINA was an application layer on top of XINU that handled the executive tasks of running a pinball machine, and also abstracted the various hardware features. We used Allegro as the graphics SDK.
The name XINA was inspired by XINU, and was an acronym for "XINA Is Not APPLE". APPLE was the previous pinball programming system, no connection to the computer company.
SG isn't making pinball machines but apparently has licensed the code to an outside group to maybe remake old games or whatever.
It’s a fantastic bit of code for anyone interested in how operating systems are designed and built.
Glad to see it’s still being kept alive!!
I’m curious about the machines used to run the code in, their boot processe, or anything you can talk about.
> XNU is an abbreviation of X is Not Unix or XNU is Not Unix.
Wikipedia says the first release of XNU was in '96 (perhaps in NeXTSTEP 4.0?), though, far later.
Right. Goes back far, too:
I particularly like EINE and ZWEI:
From the linked article:
>the two MIT Lisp Machine editors called EINE ("EINE Is Not Emacs", German for one) and ZWEI ("ZWEI Was EINE Initially", German for two)
At the time, embedded X86 boards were not really a thing yet so we needed something simple that could run with a COTS PC motherboard.
The major factor was that the licensing for other operating systems was too costly or too restrictive. Anything GPL-based was ruled out by our lawyers. Turning Linux into an RTOS would have forced us to release source code and that wasn't a fight with Legal that anyone had time for.
XINU turned out to be just what we needed. The process limit wasn't a huge problem since we were used to running threads on a single process. Adding networking later turned out to be very easy.
It took us quite some time to get everything up in a way that would work on most Purdue systems and our own personal ones and from there even translating the limited codebase we were using unsafe code blocks for nearly everything (and ASM blocks) and some internal code for multicore/ACPI-related things/Galileo boards we haven't made publicly available yet, AFAIK.
At the end of the day, Xinu was small enough and very concisely written and maintained for several decades that switching to a language like Rust wasn't warranted. Similar to sqlite, I suppose. You can email me at email@example.com if you'd like to know more details/talk to Dr. Comer about Xinu things.
(I'd love to see OS classes use Rust someday, so I'm always trying to keep an eye out for things...)