Customizing the user interface for my Mini-Computer (updates 9/2016)

More on my Mini-Computer

 One of the requirements of having a time-share computer system is having a user interface that makes everything seamless. One point to log in, and commands that allow tasks to be farmed out to the various processors with the user not having to deal with internal details.

For example, when the user type print [filename], he/she shouldn't have to know that the print spooler is on processor 1 even though he is running a program on processor 3.

Unix (and by default Linux) works very well for a lot of things. One of the things is does NOT do well is tie multiple processors together for many users. The Primos operating system, DEC's RSTS and a few others do a good job of it. They were written from the ground up as time share operating systems. DEC's RSX-11 was not. MS-DOS also was not.

When a user connect to and types on a unix-based operating system, he/she does not actually talk to the operating system. There is a program called a shell that connects the keyboard and display to the operating system. When a user types a command (ls -l for example) the shell forks the command and runs a varient of execv to execute the ls command. When the ls command is done, it exits, returning control back to the shell.

So, how does a shell know which processor the command should run on? How about load sharing? And which processor should the user connect to when they log into the computer system?

One way to take care of this is write your own shell. Add the commands for printing, running processes on certain cores, etc as built-in commands, and the rest get passed along to the operating system. This works well for a time-sharing system as data logging, connect time, etc become trivially easy.

In addition, some commands require running on multiple cores at a time. Compiling the glibc library runs a lot faster on 20 cores than 1. Tying the mpich libraries into the shell makes this possible.

I'm currently writing the shell for the mini. I'll post updates, but it'll be awhile.

Aug 11 update: I have a basic shell that allows multiple users to run a program on any of the cores. User doesn't know what's going on in the background, he/she just sees the output of the program they started.

Sept 21 update: Almost done! And surprisingly easy. I started off writing a custom shell in c. Enough internal commands to make everything work the way I wanted it. But still not perfect.

So I thought about just what I want this thing to actually do. Ended up that the build I have is not really what I wanted. What I designed originally (not what I ended up building) was to be a minicomputer that your typical school might be using for student programmers, with several extra terminals used for admin. On top of that, there would be terminals used by the teachers for their grading stuff etc. Or for use in a small to medium business - 30-80 users running the day to day operation. Databases, spreadsheets, accounting, billing, payables, etc.

So, I re-designed the user interface, and how the computer connects to the outside world. I have all 5 processor boards tied into the internal 5 port switch, and added a usb to ethernet port coming from the 1st computer. This computer acts as a gateway, and all communication goes thru it. Also the internal hard drives go to it and are shared with the other cpu's as NFS mounted drives. Which is what I have now, but the software I wrote makes it transparent to the other users.

Now when a user connects, they connect to the gateway only. The shell determines how to route the user (if need be) and takes care of handing off users to other processors when the system load gets too much on one cpu. I implimented a round-robin approach to load sharing. Initial tests show 64 users are seamlessly handled and 80 is a reasonable expectation with the software. By reasonable, I don't mean the timeshare machines of the 70's where when someone ran a large BASIC program everything stopped. With multiple machines compiling a large Fortran program, there was no noticable slowdown. The only time a cpu load goes above 10% is when X starts a massive spreadsheet, or java runs on a web page.

That's not what I'm building. The local processor can handle web surfing, youtube etc just fine. What I'm making is a computer that handles multiple users running somewhat simple tasks sharing common storage, printers, and other resources. I also started on a new front panel. The original design let me play with an 8080 simulator. That is no longer needed. What is needed is a simple way to reset individual processors, easy access for backups, and a simple status display that would show faults for anyone walking by.

Parts are on order. The shell/operating system for the mini portion is mostly done. I can now, using only the minicomputer shell I wrote, finish writing any additional code. I'm working on job control, and adding code that keeps track of cpu time per user. Basically a simple accounting package.

What originally started out as a toy is turning into something that could be easily used in a classroom setting. Maybe a computer lab. I'm writing in the security and accounting routines with this expectation. Backups of individual users are trivially easy and by plugging in a usb stick all users files can be backed up in seconds. Something a teacher could do at the end of the day. They could then pull it home to check on daily assignments.

Likewise for a small office. Backups are done at end of day, then saved off-site.




Still a work in progress.


~-~