ULIX: Literate Unix
A diary documenting the implementation of ULIX-i386
|
Welcome to the ULIX blog.
Ulix (Literate Unix) is a Unix-like operating system developed at
University of Erlangen-Nürnberg.
I use D. E. Knuth's concept of
Literate Programming
for the implementation and documentation. The goal was a fully working system which can be
used in operating system courses to show students how OS concepts (such as paging and scheduling)
can be implemented. Literate programs are very accessible because they can be read like a book;
the order of presentation is not enforced by program logic or compiler restrictions, but instead
is guided by the implementer's creative process.
Ulix is written in C and assembler for the Intel architecture. The literate programming
part is handled by noweb.
On this page I document my progress with the implementation.
|
|
Navigation:
2015 |
2014 |
2013 |
2012 |
2011
|
| v0.09: IDE Disk, exec, vi (02.11.2013) | |
For a few months, Ulix has been able to use IDE hard disks. There's now also a
virtual filesystem layer which lets the system mount hard disks and floppy disks
to sub directories (but that's not complete yet; so far only one mounted device).
I've also written execve() which loads ELF binaries. Many tools which were shell-built-ins
have now become "proper" external commands, residing in a /bin/ folder. The first real
application is an ultra-simple vi clone: so far the editor can open and save files,
switch between command and edit mode and actually insert/delete text. The only working
commands are dd (delete line), x (delete character), wq (write and quit), and
q! (quit without saving). The picture shows vi editing a C file.
The next release should see a completion of the virtual filesystem (with mount / umount
commands) and the signaling code mentioned earlier.
[ Path: | persistent link ]
| |
| Buffer Cache (19.07.2013) | |
After noticing that disk access is pretty slow (because many blocks
are being read over and over again) I introduced a simple buffer
cache which can store 256 disk blocks im RAM. This has really sped
up the access times; reading and writing feel normal now.
Currently only read operations are buffered. Maybe later I'll also
buffer write operations and add a sync system call; but reading
occurs much more often than writing.
[ Path: | persistent link ] | |
| Filesystem: Directories, link, unlink (15.07.2013) | |
The Minix code is almost complete: Ulix can now access sub-directories and
files inside those. Relative paths are converted into absolute paths, and
the new functions link() and unlink() are finished. This can all be tested
in user mode, the shell has built-in commands cd, touch, cp, ln, rm.
All filesystem actions have been tested (with fsck.minix), they all leave
the filesystem valid.
What's missing is little things (mkdir, rmdir, symlink; I'll add those in
the next days) and double
indirection which I won't implement, it is only needed for files larger
than 263 KByte, and those are not likely on 1.44 MB floppies.
[ Path: | persistent link ] | |
| Having Fun with Minix (13.07.2013) | |
As I wrote in the last entry, I have implemented (parts of) the
Minix filesystem. I used that one because Linux machines can
create and mount Minix filesystem images. However, I use a Mac
for development, and on those machines it is harder to access
Minix volumes. The MacFUSE-based "minixfs" command can mount a
Minix image, but only read-only, and I have not found software
that can mount them writeable on the Mac.
So I created a small VirtualBox VM with Debian inside, shared
the Mac's filesystem with the VM and created shell scripts
which mount the Minix image and modify it. I had to learn that
this approach doesn't work when the image resides on the
vboxsf shared folder: Files kept disappearing from the image.
The solution was to first physically copy the image into the
VM, mount it, make the changes, unmount it, and copy it back
to the Mac. It works now :)
[ Path: | persistent link ] | |
| v0.08: Floppies, Minix Filesystem (13.07.2013) | |
Ulix reads and writes floppy disks (via the FDC controller),
it can handle parallel accesses from several processes (using
a mutex to synchronize things). There's a basic implentation
of the Minix (v2) filesystem: Via standard system calls, processes
can open, read, write, lseek files, and single indirection for
block numbers is possible. No double indirection, and currently
no sub-directories. (The Minix code replaces the older
simplefs filesystem which was a very basic FAT-type system.)
Next: Implementation of signals. There's already a kill()
function and the corresponding system call, but the scheduler
needs modification (for jumping into signal handlers when
signals are found).
[ Path: | persistent link ] | |
| ULIX course at Nuremberg University of Applied Sciences (30.05.2013) | |
Next term (winter 2013/14) I'll offer a course called "Operating
System Development with Literate Programming" at
Nuremberg
University of Applied Sciences (Technische Hochschule
Nürnberg). I'll introduce the literate programming
technique, show ULIX code fragments as examples and let the
students implement further ULIX components as literate programs.
When that course starts, ULIX should be sufficiently developped,
so this gives me a nice deadline for completing the basic code.
[ Path: | persistent link ] | |
| Virtual Consoles, Multiple Shells (30.04.2013) | |
The latest addition to Ulix is that it now supports ten virtual
consoles, each of which can host a shell. That way it is possible
to start tests on one console and watch its behavior (e.g. by
displaying the process list) on another one.
[ Path: | persistent link ]
| |
| v0.07: Scheduling, fork(), exit(), and waitpid() are working (05.04.2013) | |
It's taken some time, but I finally got the context switch working,
and so Ulix can now launch new processes and have them all run in
parallel by the (simple round-robin) scheduler. The problem was in the
function which changes the address space (by modifying the CR3 register
which points to the page directory). For some time I thought it should
be sufficient to make that function an inline function, but now I found
that it must not be a function at all (there's still parameter-passing
involved in calling inline functions, and these parameters are lost
when changing the page directory). So now it's not a function call anymore,
instead the scheduler directly switches the page directory,
and everything works.
The first two Bachelor theses (on Ulix-Filesystem/RAM disk and the ELF binary
loader) are completed, so after I've included the code in Ulix, it will be
able to start programs from disk properly. The third student who is working
on a priority-based scheduler is also about to complete his work in the next
weeks.
[ Path: | persistent link ] | |
Copyright © 2011-2015 Hans-Georg Eßer;
Server: Debian Linux, Apache Web Server,
blog page powered by blosxom :: the zen of blogging,
Theme: Hazard Area 1.6 (modified),
created by Bryan Bell,
Copyright © 2000-2006 Weblogger.com.
|
