AMOS 0.5.0 Released

[spacedsteve]

Released 0.5.0 with the near finished process manager subsystem and lots of bugfixes. A simple user shell application is included along with a test application. Each virtual console has an instance of the shell spawned on it so you can finally interface with the kernel via a pretty good set of system calls. Each process spawned is a user mode process (ring3) with its own address space so theirs good separation and protection between multiple processes in the system. The test application lets you perform some illegal operation to stress test how stable the kernel is, so you can perform page faults, general protection faults and the like at will. The kernel process (ring0) after initializing the kernel itself and spawning the initial shells turns into the systems idle process. I have tested 0.5.0 on VMWare, Qemu and Bochs and it seems to be pretty stable. Their are some known issues with the FAT driver; still no write support and some small bugs with file/path naming. Also virtual mount points are not included within list operations.

Press F1, F2, F3 and F4 to navigate through the 4 virtual consoles, press F5 to see the schedulers current process table.

The basic shell commands are, TAB to see a list of available commands or auto complete the current command you are typing in. spawn to spawn a process, e.g. >spawn /boot/test.bin (all file must be addresses with absolute paths, no relative addressing yet) dump to dump a file ontents to screen, e.g. >dump /boot/menu.cfg. kill to kill a process, e.g. >kill 9 to kill process 9. list to list the contents of a directory, e.g. >list /device/, to list the contents of the device directory. commands like copy, rename and delete are also available (copy isnt implemented in the FAT driver yet).


Download the source code or binarys here:
AMOS 0.5.0 release (SourceForge.net)

And finally some screenshots of AMOS running...

[Solar]

Haven't tested it (yet?), but I sure like the idea of the test app that triggers the various CPU faults for testing. Too bad you don't have that comfortable option handy when you're implementing your fault handlers the first time...

[Warrior]

Wow this is really starting to shape up. I'll do some testing soon

[spacedsteve]

cool thanks for the positive feedback

[DennisCGc]

Hi,

I gave it a test on my dedicated test pc (p1 166 mhz) and I worked well. Gave the test app a try, killing processes works great. Listing files & dirs are also working great!

One thing that noticed me though, floppy disk loading is slower than normal. Could be the pc or diskette, or it could be your driver.

Anyway, nicely done!

DennisCGc.

[edit] just tested the copy command. the command seems to fail though. Tried: copy /boot/test.bin /boot/test2.bin and it immediatly returns failed to copy. [/edit]
[edit2] I should read better [/edit2]

[spacedsteve]

thanks DennisCGc, ill look into the floppy driver to see if their is a performance issue. The next release should finally have the finished FAT driver with write support too

[hendric]

I think it funny and have already done some tests on my bochs(with 8 processors).Well running.Any additional tests required?

[rootel77]

hi,
first, thanks for the well commented code.

i've took a look (excuse my english) at the memory manager code. I have some doubts about this code :

Code: Select all

for( new_item=kernel_process.heap.heap_bottom ; new_item!=NULL ; new_item=new_item->next )
   {
      if( !new_item->used && (total_size <=  new_item->size) )
         break;
   }
   // if we found one
   if( new_item != NULL )
   {
      tmp_item = (struct MM_HEAPITEM *)( (int)new_item + total_size );
      tmp_item->size = new_item->size - total_size;
      tmp_item->used = FALSE;
      tmp_item->next = new_item->next;
      
      new_item->size = size;
      new_item->used = TRUE;
      new_item->next = tmp_item;
   }

if total_size == new_item->size ther is no need to split the block.

and also about this code

Code: Select all

else
   {
      // didnt find a fit so we must increase the heap to fit
      new_item = mm_morecore( &kernel_process, total_size );
      if( new_item == NULL )
      {
         // unlock the critical section
         mutex_unlock( &mm_mallocLock );
         // return NULL as we are out of physical memory!
         return NULL;
      }
      // create an empty item for the extra space mm_morecore() gave us
      // we can calculate the size because morecore() allocates space that is page aligned
      tmp_item = (struct MM_HEAPITEM *)( (int)new_item + total_size );
      tmp_item->size = PAGE_SIZE - (total_size%PAGE_SIZE ? total_size%PAGE_SIZE : total_size) - sizeof(struct MM_HEAPITEM);

if the remainder size after allocating total_size is less than sizeof(struct MM_HEAPITEM) then tmp_item->size will be negative. if total_size is page aligned the same situation as above occurs

[spacedsteve]

hi rootel, thanks for that and excuse they *very* late reply as I have been away. I will look into your sugestins and fix up the code as needed for the next 0.6.0 release. Thanks again

[mystran]

FYI: I tested in Bochs 2.2.6, from the binary image, and it booted fine, run fine.

But I must complain that it is truly confusing that you have to specify path with all those / characters. It's not so bad that you need a leading one (for full path) but it's strange that you need a trailing one to list directory contents..

Basicly, one would except list /boot to work..

[spacedsteve]

the shell as yet has no concept of relative addressing so you must specify the full path. The trailing forward slash must be used with directory's to differenciate them from files. The VFS needs some work to tidy up file/directory addressing ill admit, the list() system call sucks in its implementation, but its only a small feature in the grand scheme of things thanks for checking it out.

[mystran]

Played some more with the test app, and:

Code: Select all

AMOS 0.5.0
--------------------------------------------------------------------------[1]---
    EFLAGS:0x10206  SS0:0x23 ESP0:0x20000000
remove process 6...
destroying process 6...
AMOS:>spawn /boot/test
Test App
    1. Exit Gracefully!
    2. General Protection Fault
    3. Page Fault
    4. Divide By Zero
    5. Stack Overflow
    6. Invalid Opcode
    7. Loop Forever
Please enter your choice2 4
About to divide by zero...
Exception "Divide By Zero" in process 7
    CS:0x1B EIP:0x100003CB
    DS:0x23 ES:0x23 FS:0x23 GS:0x23
    EDI:0x0 ESI:0x0 EBP:0x20000FC8 ESP:0xD003BFF0
    EBX:0x0 EDX:0x1000020F ECX:0x1000020E EAX:0x0
    EFLAGS:0x10246  SS0:0x23 ESP0:0x20000FA0
remove process 7...
destroying process 7...

Then it just hangs.

It doesn't hang every time. In fact, it seems to hang on 3rd try. I also did get it to tripple faults, just running /boot/test repeatedly.

I noticed something strange about this bug: my motherboard or something is a bit noisy when there's system activity (and sometimes when there isn't, but that's more rare). It makes quiet, high-pitched noise. First I was annoyed, and thought of getting a new one, but then I forgot (it's not that loud), and now I kinda like it: it let's me hear things happening inside my computer. It's a bit spooky though.

So, when I start /boot/test for the 3rd time, it starts keeping noise, like if there was lots of activity. That continues while the test is waiting for keyboard input. So I think you should try to catch the bug after two successful faults.

[spacedsteve]

hmmm, I have the 0.6.0 release nearly ready, in it I fixed a major problem with the physical memory manager which was causing tripple faults upon successive process spawning, so it sounds like you have come accross that bug ...allready fixed, phew

as for the noise/cpu activity, possibly a problem in the scheduler I will look into.

Cheers mystran.

[mystran]

as for the noise/cpu activity, possibly a problem in the scheduler I will look into.

Btw, suggestion: put some CPU activity indicator somewhere. My kernel for example always sets the top-right corner of screen to '*' when it schedules something, unless it schedules the idle thread (that halts the processor) in which case it sets the same character position as '.'

That way looking at the top-right corner of screen immediate tells me whether something is currently running on the CPU. It's been very useful so far.

I also have an animation with the class turning line in top-left corner to see if my scheduler is getting called and interrupts are working (it uses timer to update once every second) but...

[spacedsteve]

nice idea with the */. combination, I must check your os out.

In AMOS if you press F5 on the keyboard the kernel will dump the schedulers process table to the current consoles standard output. This lets you examine what processes are in the system and what is running. Process 0 is the idle process so you know when that is running their is no cpu activity.