Xinu – A small, elegant operating system | Hacker News Reader

Xinu – A small, elegant operating system

xinu.cs.purdue.edu

229 pointsrspivak73 comments

Open articleView on HN

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.

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...

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

> 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.

> 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.

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.

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.

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.

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

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?

[1] https://en.wikipedia.org/wiki/Star_Wars_Episode_I_(pinball)

[2] https://en.wikipedia.org/wiki/Pinball_2000

Pinball 2000 engineer here.

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.

So cool. This is why I always go to HN comments!!

I'm curious, does the source code for XINA still exist?

It does, but it's owned by whomever owns the Williams IP. I believe these days it's Scientific Games.

SG isn't making pinball machines but apparently has licensed the code to an outside group to maybe remake old games or whatever.

The professor who made Xinu, Douglas Comer, also contributed heavily to TCP. https://en.m.wikipedia.org/wiki/Douglas_Comer

Non-mobile: https://en.wikipedia.org/wiki/Douglas_Comer

It's weird that Wikipedia redirects mobiles from the non mobile version to the mobile version, but doesn't redirect the other way around.

That’s likely because I’ve seen a lot of people working on Wikipedia either via code or via content, prefer the mobile version even on desktop. It’s a pleasant reading experience.

That's curious to read because I find the non-mobile version a significantly more pleasant reading experience. I don't even like the mobile version on my phone because I constantly get lost in page when I expand sections (maybe that's just down to my dyslexia?)

Yes! I hate the expanding sections 'feature' on mobile Wikipedia. Just give me one long scrolling page with anchor links in a table of contents, like the way the web has worked since the 90s.

Hiw many years has it been, and Wikipedia Mobile still has the bug where pressing Back loses your downwards scrolling, since all sections contract momentarily (moving your page position upwards).

The second book is, indeed, all about Xinu's internetworking system. (-:

Crap this article jogged my memory - I now remember Xinu from when I was a teenager!

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!!

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.

Milenkovic's book on KMOS was rather underrated and overlooked, I found. It covered a couple of things that Comer and Tanenbaum did not.

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.

What would you like to know? I did help set up a few things there. There's a special netboot-like version of Xinu deployed on the backend systems which are just Beagle/Galileo/whatever's been upgraded, and they deploy whatever Xinu image you've supplied. Students typically compile locally and submit the xbin (compiled kernel image) to a backend.

The name seems to have the same derivation as the name of the XNU kernel underlying Apple's operating systems:

> 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.

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.

GNU's Not Unix

Do note that Xinu (1981) predates GNU (1983) by several years.

>The recursive acronym "something is not something_else" is a pretty common naming convention in software

Right. Goes back far, too:

https://en.wikipedia.org/wiki/Recursive_acronym

https://en.wikipedia.org/wiki/Recursive_acronym#Notable_exam...

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)

There is nowadays also DREI which officially stands for "Drei replaces EINE's inheritor" or alternatively for lots of other things (see the source for list), particularly "Drei reimplements Emacs intelligently".

Wow, that's cool too. I'm going to create the next one, VIER, for "Vier Is EINE's Replacement".

https://translate.google.com/#de/en/Vier

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.

Curious to know if anyone has used this for anything serious, and what the main decision factors were for choosing Xinu?

They have a whole list on that page. Lexmark printers in the 90s, for instance, used Xinu.

Interesting, I worked at Lexmark for a few years and didn't know that. One of my professors at the University of Kentucky worked on Xinu, I wonder if he had any influence on it being used at Lexmark (the university and company are both based in Lexington, KY)

Printers sold by Lexmark until 2009 used Xinu onboard. Now they're some lightweight Linux.

I expect that it's role in the OS ecosystem is mostly taken up by projects like FreeRTOS.

In 1999 my team at Williams Electronics chose XINU as the O/S for the Pinball 2000 project:

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.

Did you look at MINIX?

I don't recall. The lead O/S engineer was from Purdue so perhaps he went to XINU right away out of familiarity.

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.

What didn’t work?

We had tremendous difficulty convincing Dr. Comer that using an experimental/nightly toolchain to compile an experimental compiler variant to use experimental libraries in an experimental language was worth it.

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 avaidyam@purdue.edu if you'd like to know more details/talk to Dr. Comer about Xinu things.

Ah, okay. That all makes sense! I thought you meant that like, the language couldn't do it at all. All the stuff you've said is the current state of things, roughly, for sure. Thanks!

(I'd love to see OS classes use Rust someday, so I'm always trying to keep an eye out for things...)

No worries - while I personally enjoyed Rust it was clear that it was unsustainable for Dr. Comer. He means the best, I assure you. :)

Google cache: http://webcache.googleusercontent.com/search?q=cache:rNJQhgs...

https://www.bing.com/videos/search?q=xinu&&view=detail&mid=7... 1st in the video list while investigating. ha ha

Wow, development started in 1980! That's commitment.

In this particular case, I’d say it’s academic research.

Not mutually exclusive ;)

Sure, but still.

Reply on news.ycombinator.com