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`:
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.
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.
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.
Was curious about one thing. On the Xinu website, under "Xinu in industry" in the 2000s, it says that the pinball game for Star Wars: The Phantom Menance uses Xinu. So I looked up that pinball game.
On the wikipedia page for the game [1], it says that it uses Pinball 2000 hardware. And on the wikipedia page for Pinball 2000 [2], 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.
Same here. I learned the rudiments of operating systems by studying Xinu in college. That was pre-Internet, so text books like Xinu's were hugely helpful.
I took classes with Doug Comer in college and I also maintained part of the Xinu lab while I was at Purdue. Great to see the impact it has had on OS education outside of Purdue!
Can you talk about the machines in the lab. I’m in WL and have seen in Greyhouse and in Lawson people battling with XINU enough that I’ve gone over to see what they’re doing.
I’m curious about the machines used to run the code in, their boot processe, or anything you can talk about.
The recursive acronym "something is not something_else" is a pretty common naming convention in software. Much like how there are a hundred different software projects out there called "Yet Another something". So I'm not at all surprised we occasionally get collisions. Still makes for a fun coincidence though.
I think it's just Unix backwards. One of my professors worked on this and used it for many examples in our OS course. I can't remember if he said that or if it's just what I thought when I saw it.
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.
There are a few classes in Purdue's CS undergrad program (at least as recently as a couple years ago) which leaned a lot on XINU to teach OS fundamentals. Specifically in the 400-level Operating Systems course, we had one lab toward the end which reached into Linux for some basic stuff, but otherwise it was pretty much all XINU; playing with memory allocation, writing a new process scheduler, stuff like that. Purdue maintains a lab of XINU computers, which I believe are just Linksys routers of some kind, which students can log in to from anywhere to complete lab assignments, including a scheduling hypervisor which ensures that we weren't stepping on each others toes given there were only ~30 machines.
Not Linksys routers! They're typically Beaglebone/Galileo cards or something newer now. They actually run a special netboot-like version of Xinu that deploys your compiled xbin. (So it's like Xinu running Xinu...) There also was no such hypervisor, mostly TAs that responded to email complaints and took systems offline when hogged on accident.
Once upon a time, a colleague and myself attempted to rewrite Xinu in Rust to show Dr. Comer how cool it was. Rust did not work. It was not cool. Dr. Comer simply smiled a gentle "I told you so," as he had good reasons for sticking to C.
[+] [-] ww520|7 years ago|reply
* 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.
[+] [-] LukeShu|7 years ago|reply
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`:
[+] [-] zealsham|7 years ago|reply
[+] [-] pmorici|7 years ago|reply
[+] [-] gmueckl|7 years ago|reply
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.
[+] [-] JdeBP|7 years ago|reply
[+] [-] userbinator|7 years ago|reply
Edit: downvoters, care to explain...?
[+] [-] ranit|7 years ago|reply
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.
[+] [-] fernly|7 years ago|reply
[0] https://xinu.cs.purdue.edu/cont.html
[+] [-] cabaalis|7 years ago|reply
On the wikipedia page for the game [1], it says that it uses Pinball 2000 hardware. And on the wikipedia page for Pinball 2000 [2], it uses Xina (Xina is not Apple) and not Xinu. Is there another variant of the OS?
[1] https://en.wikipedia.org/wiki/Star_Wars_Episode_I_(pinball)
[2] https://en.wikipedia.org/wiki/Pinball_2000
[+] [-] koz1000|7 years ago|reply
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.
[+] [-] aarya123|7 years ago|reply
[+] [-] Nicksil|7 years ago|reply
[+] [-] JdeBP|7 years ago|reply
[+] [-] jarym|7 years ago|reply
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!!
[+] [-] facorreia|7 years ago|reply
[+] [-] j6jr85ehb7|7 years ago|reply
[+] [-] rovr138|7 years ago|reply
I’m curious about the machines used to run the code in, their boot processe, or anything you can talk about.
[+] [-] rgovostes|7 years ago|reply
> 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.
[+] [-] laumars|7 years ago|reply
[+] [-] Delfino|7 years ago|reply
[+] [-] GordonS|7 years ago|reply
[+] [-] koz1000|7 years ago|reply
https://www.youtube.com/watch?v=8rHbsCyde1g
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.
[+] [-] deaddodo|7 years ago|reply
[+] [-] corerius|7 years ago|reply
[+] [-] 013a|7 years ago|reply
[+] [-] avaidyam|7 years ago|reply
[+] [-] avaidyam|7 years ago|reply
[+] [-] steveklabnik|7 years ago|reply
[+] [-] vonkale|7 years ago|reply
[+] [-] usermac|7 years ago|reply
[+] [-] nkkollaw|7 years ago|reply
[+] [-] EmilStenstrom|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] 6031769|7 years ago|reply
[deleted]