Skip to content

Unlink Fixed

Working again. Back to the editor.

Unlink Broken

In working on the text editor I notice that the unlink system call, to delete a file, appears to be broken. It was working fine a while ago so I’ve obviously changed something. Ho hum – one step forward, two steps back.

As an aside, I’ve been thinking about the best way to publish patches for minor problems like this. I could make the svn archive open for public read access, or just post the updated files in links here or in a Downloads directory. Alternatively I can create a new tar.gz of the whole source code every time.

Any preferences?

Updates to System

It seems like ages since I added anything to the website. Not surprising, as it is ages. But I have been working, on and off, on the system and have now made what I think are significant improvements, and have improved the stability considerable, so I present them for your entertainment.

Those of you who have looked at IanOS in the past will notice:

1. I have now adopted the standard UNIX/Linux system calls, with just one or two of my own. The hope is that one day – in the far, far distant future – I may get to the stage of porting software from Linux.

2. The console task now supports multiple consoles. Sounds easy but it involved a lot of work.

3. I’ve written a few more user programs, and I’m in the process of writing a simple text editor. This will, I think, be the first really useful program. One day I’d like to produce, or port, an assembler and C compiler so that the system could compile itself. Well, we can all dream.

4. The filesystem has been improved considerably with working support for directories, files that use more than one disk cluster, etc. It’s still a bit rough but I’m getting there.

All round, the system is more stable, more versatile and, I hope, better commented and documented. I’m aware that there is room for improvement in the documentation and I am looking into this.

As I work on the system further I’ll try hard to keep this blog updated. But, don’t forget, it’s all just a fun project and sometimes I have other things that attract my interest. So bear with me if I sometimes neglect this little project.



Latest Version Uploaded

I’ve now updated the documentation and uploaded the latest version which includes all the changes mentioned here to date. Let me know if you spot any problems or bad links.

First Real Program!

I’ve now implemented the first useful program – a very simple version of “ls”. It’s not much, but it’s a start!

Interesting how many bugs come to light when doing something like this. A particularly nasty one was the situation when a memory allocation was called for with a requested size of zero (of course this should never happen, so a few more checks are needed). The result was that the first memory entry in the list was used (even though it was already allocated elsewhere) and susequently deallocated, with unpredictable results. That was quite a tough one to track down as it didn’t show up immediately. As always, without SimNow I don’t know how I’d ever have found it.

When I have the energy I’ll try to document this latest version and upload it to the web site as I think it represents a significant step.


Whilst modifying the memory allocation routines to include the Pid of the task that owns the memory it occurred to me that I had made the most elementary oversight by not accounting for the possibility of multiple tasks trying to allocate memory at the same time. In the wrong circumstances this could cause havoc by completely wrecking the linked lists of memory allocation. The answer is trivial – I have now implemented a system of semaphors so that only one task can access the memory allocation/deallocation routines at a time.

This is almost trivial on the x86_64 processors by using the CMPXCHG instruction. This tests and, if required, sets a memory location as an atomic instruction; in other words, it is guaranteed that the instruction will complete without being interrupted. If the semaphore can’t be set (i.e. if another task has already set it) a task switch is done and the operation will be retried next time the task runs.

At the start of the memory allocation/deallocation routines a semaphore is now set, and it is cleared at the end of these routines. This should guard against the possibility of some particulary obscure bugs at a future time.

Resource Allocation/Deallocation

The more I work on the system the more obvious it is that I’m going to have to be a little more clever when allocating and, particularly, deallocating memory. I’m most concerned with deallocating memory when a task ends. User heap memory is no problem, as it is part of a memory map that gets discarded and (I think) kernel heap allocation doesn’t occur in user tasks. However there is still shared memory to worry about. Currently it’s up to the task to make sure that it deallocates everything – but that’s really not good enough; it should happen automatically.

I’m thinking at the moment of adding an additional field to each allocated block of memory to record the task of the PID that it belongs to. A separate task could then clean up resources once a task ends (and perhaps periodically sweep the system looking for zombie resources). It doesn’t sound too difficut to implement.

Actually, I’m not totally convinced that the use of shared memory is a good thing (except where absolutely necessary) – there are obvious security implications. It’s needed to pass information between tasks (other than the limited amount of data that can be passed directly in a message), but there must be an alternative way of doing this. I must look carefully at where shared memory is used and whether it is necessary.

There’s also the separate problem of keeping track of which task an FCB belongs to so that the filesystem can deallocate it when it is no longer needed.

SimNow and Fedora 11

I bought a new laptop the other day and installed Fedora 11 on it, only to discover that SimNow didn’t work. I’ve now installed Fedora 10, and things work fine. I don’t know whether it’s a problem with the latest kernels or libraries, but it’s worth bearing in mind. I’m guessing this problem may affect the cutting-edge versions of other distributions.

File System Nearly Finished

Work on this is now pretty much complete for the time being. It turned out to be much easier than I anticipated. Write access now works; directory structure and time stamps don’t. I’m not too bothered about a directory structure right now, as the root directory can hold 512 entries – in any case I don’t intend FAT to be the long-term file system, so I don’t want to do more than the necessary minimum of work on it. Time stamping would be of little use until some form of time-of-day clock is implemented (shouldn’t be too difficult). I’ll now work on documenting and publishing this latest version.

What next? Current work has shown up a problem when running under QEMU; sometimes it needs two or three attempts before the system runs. These problems don’t occur under SimNow, so I’m guessing it’s a question of uninitialized variables. Other than that, I think that I’ll look at implementing a few simple commands – cat, ls, cp, that sort of thing. Another thing that I think I may look at is changing the memory map to give more available memory to the various parts of the system.

Disk Journalling in SimNow

Work on adding write ability to the filesystem is progressing nicely, but I was momentarily disconcerted by a little detail of SimNow. By default, all disk writes are journalled; this means that, unless you disable this feature or manually commit changes, changes won’t be saved to the disk image. I wondered why my disk writing routines seemed to be working when looked at under the debugger but weren’t saving anything permanently to the disk! Have a look at the manual to find details of this feature (which I can see is actually very useful when you are experimenting).

By the way, there’s a new version of SimNow out that allows you to add and delete devices from the virtual machine that you are using. It also seems slightly faster to me, but that could well be a combination of my imagination and changes that I have made to IanOS.