I’m of two minds regarding this ‘discovery’. On the one hand it’s great knowing that there could effectively be an unlimited supply of crude oil in the world - could this be the start of the road to free energy? Could this possibly mean an end to wars and and rivalry over oil rich countries?

However, I do have my concerns. Is this really the best thing for the environment - yes, it’s a way of recycling our waste. It’s also a means of gaining oil without the hassle of drilling and pumping and who knows whatever else - but is it sustainable for the environment and planet - do we really want to continue to have cars that pump out masses of CO2 or, would we prefer to find alternatives such as hydrogen power etc? Another interesting question - how much oil can these bugs really produce - too little, or as one critique on the news article says “Suppose some of these bugs mysteriously got out of the laboratory and into the environment. Would they not continue to behave in a similar fashion outside the petrie dish? So now everything around them would slowly be converted to oil. How is this scenario “environmentally friendly”?”. Then there are the moral grounds - is it right to genetically modify bugs for such things? Should we be playing God?

Overall I think it’s an interesting step, and it may even be a step in the right direction towards sustainable, environmentally friendly fuel - but I still think we’ve got a long way to go.

So after a interesting Solaris Advanced Crash Dump Analysis course last week (which has really put me back into my OS development mood) I decided it was time to make a move and I spent a large portion of Friday night working out how to allocate memory without overwriting the existing kernel, and at last by about 2am in the morning having messed around with the linker and some cleverly placed assembly labels I finally was able to kmem_alloc() some memory.

At this point I decided I was finished and went to bed. The next morning I awoke, pleased to have kmem_alloc() working, or so I thought. However, as the day progressed and I allocated more and more pages of memory I started to see some strange things happening. Why did that character on screen just go red? I never put a start on the screen…

After a fair amount of time debugging the issue I managed to isolate the problem. My array of free_pages_t structures were located, not at the end of the kernel stack as I thought (which is currently 8K), but in the last 1K of the stack. Ultimately the problem was a off by one (er, or 1024 depending on how you look at it) error in my programming. At last I was able to kmem_alloc() pretty much as much memory as  I wanted - but how to free.

This proved to be very easy. I simply modified my page_map_t structure to contain a grouping id. As such, when we call kmem_free(void *) we do the following to first make sure that the address we got was on a page boundary.

	while ( (addr % (PAGE_SIZE * 1024) != 0 )
		addr--;

	while ( page->addr != addr )
		page = page->next;

Now we’re on a page boundary we can just loop through the pages whilst the alloc_id’s are equal and set the flags to PAGE_FREE…

	int alloc_id = page->alloc_id;

	while ( page->alloc_id == alloc_id ) {
		page->alloc_id = 0;
		page->flags &= PAGE_FREE;
		page = page->next;
	}

With that working I then spent a bit more time perfecting and tweaking and now MouthOS is pretty good at allocating and freeing memory - at least, I think it is anyway. In the end it turned out not to be so difficult - you just have to get your head around the whole idea of allocating memory, before you have an allocator. When I thought about it this ended up not to be such an issue after-all….  Here is how we can do it.

1. You know the point where your kernel loads.
2. You can work out where your kernel ends by putting a label in its own section, and then using the linker to put that section at the end of the kernel.
3. You now know (from the placed label) where a safe place in the memory is to write without overwriting the existing kernel, so write all your required memory structures, of which you can calculate how many you need from the amount of memory in the system.
4. Finally,go back to your memory structures that you’ve just written and mark all the kernel space as allocated, including the space the memory structures take - which you know as you know the size of a memory struct, you know where it starts, and you know how many you’ve got.

Easy You can find the code for the new MouthOS memory allocator at: http://www.michael-clarke-blog.com/trac/MouthOS  -  if you’re remotely interested :p

Until next time.

As some of you will know, I was going to be the Campus Ambassador for Aberystwyth University. However, recently Kim Austin (who is in charge of the Campus Ambassador program in the UK) asked if I’d like to be the Campus Ambassador Co-ordinator instead.  This job basically involves supporting the student ambassadors out in the field with their technical demos and day to day job requirements. Having worked for Sun for a year in the UK head offices I understand what Sun wants from the campus ambassadors, and being a student myself I also understand what students want from the campus ambassador program. It is my job to make sure that both parties get what they want.

So, why the new blog? I thought it would be nice to have an official blog for the Campus Ambassador work so that those who aren’t interested in MouthOS, or  that my bike tire still hasn’t been fixed (I’m waiting for the inner tube, honest… I’m not that lazy!) can keep a track of all the stuff that is going on in the world of campus ambassadors.

At the moment I’ve not got much on my new blog at the moment, but you should check it out for all the latest Campus Ambassador news in the UK.

http://www.michael-clarke-blog.com/trac/MouthOS

The older versions are in /proto. Kernel version 0.0.1, 0.0.2 and 0.0.3 are broken with some pretty big bugs (for such small programs) such as triple faults and Kernel panics.

The most stable version at the moment is version 0.0.03 in /releases.

The stuff in /trunk is the current development with all the new HAL (Hardware Abstraction Layer) stuff. I’m still in the process of porting a lot of the proto-0.0.3 and releases-0.0.3 stuff to /trunk - so this is pretty useless at the moment But you’ll get the general idea as to where the project is heading from /trunk in terms of the HAL, Memory Management etc.

At some point I’m also going to add anonymous svn access so you’ll all be able to checkout the source code and have a play - but at least for the moment you can view the code, the wiki etc.

For the moment - enjoy

So, we met at Sun about 3pm with plenty of water and every tool under the sun that we could possible need. The plan was to cycle to Fleet, then around Fleet lake and perhaps pop into The Heron on the Lake for a quick pint before cycling back - no too bad at all.

Things were going excellently - we arrived at fleet and got about 1/2 way around the lake when Vlad pulled up and said - “your back tyre is looking a little low”. No problem we thought - we’ll just pump it up a bit and off we go. No such luck - the inner tube had rotated slightly in the tire resulting in the valve being at such a funny angle that no pump would attach to it. No matter what we tried we couldn’t move the inner tube around so in the end we figured we’d just have to let the whole tyre down, move the inner tube around, and then pump it up again.

We were soon pumping the tyre up again - but every time we stopped there was a loud hissing - puncture. Unfortunately the puncture turned out to be right on the valve - probably because the inner tube had pinched… No puncture repair kit was going to fix that and the only inner tube we had was too big for my tyre.

After some debating I decided the best thing to do was to leave my bike nice and hidden in the bushes. Walk home (about 1 1/2 hours), pick up the car and then drive back to pick up my bike. The only problem with this truly cunning plan was that Vlad and I weren’t entirely sure where we were… all we knew is we were approximately 1/2 way around the lake (though it later turned out to be 3/4 way around the lake - throwing our directions off slightly).

However, all was not lost. Vlad’s mobile had GPS on it and so we were able to walk roughly in the direction of home. At one point we slightly overshot our turning and the distance started increasing so I decided to take a shortcut through some woods rather than following the path. This seemed quite productive until we hit a locked gate next to a road… wondering why the gate onto the woods we’d just walked through was closed we climbed over and then saw the ‘DANGER! Army Training Grounds. DO NOT ENTER” signs in bright red coupled with the ‘Do NOT pickup suspicious objects” with a delightful picture of an explosion - oops.

Anyway… this is basically where the excitement ended. From here on we walked home, got the car, picked up the bike and then decided a BBQ was an excellent idea… the only think I’m regretting about the whole experience is that our chosen location for our attempted repairs on my bike was riddled with midgies - I now have rather red, bumpy and itchy legs I count approximately 16 bites on one leg and 44 on the other… time to go to the super market and pick up some cream for insect bites me thinks…

On a lighter note it turns out that Friday was Fraser’s (my house mate) birthday. He kept that very quiet - the only reason I found out was because I saw one of his cards…. As such we bought a cake which we all consumed after the BBQ last night.

I’ve got to admit that being down south in Farnborough for the last year really makes you appriciate the views back home that you normally just take for granted.

le/why/has/this/moved/here?puter ~ $ mplayer /some/long/path/to/some/fi

That is really really really annoying when it happens.

Anyway, a colleague mentioned some time ago that this was the reason he moved back to Korn Shell… so I figured I’d give it a go. So far the only thing I’ve not managed to get working is coloured ls output…. Everything else is working, tab completion (even though I’m trying to use Esc + \ instead), coloured PS1 prompt etc etc … most importantly though, vi mode hasn’t, as of yet, messed up!

I’m starting to get a little concerned though - I’ve moved away from Gnome to Fluxbox at home and to fvwm2 at work… then on top of this I’ve now changed my shell from bash to ksh - what is happening!?!

Edit: I’ve now got coloured ls working… I was too involved reading the .bashrc files in Gentoo trying to work out how bash does it… instead I should have just typed man ls….

  --color[=WHEN]
    control whether color is used to distinguish file types.  WHEN may be `never',
    `always', or `auto'

Duh!

michaelfclarke@mikes-computer michaelfclarke $ alias ls
ls='ls --color=always'

First, as with the Java, we need to create our API. However, unlike the Java there is an additional requirement - a ‘module manager’ class needs to be within the API. As such you will need to create these two files…

using System;
using System.Reflection;

namespace com.michaelclarkeblog.api {

  public static class ModuleManager {

    public static Module getInstance(String fileName) {

      /* Load in the assembly. */
      Assembly moduleAssembly = Assembly.LoadFile(fileName);

      /* Get the types of classes that are in this assembly. */
      Type[] types = moduleAssembly.GetTypes();

      /* Loop through the types in the assembly until we find
       * a class that implements a Module.
       */
      foreach (Type type in types) {

        if (type.GetInterface("Module") != null) {

          /* Create a new instance of the 'Module'. */
          return (Module)Activator.CreateInstance(type);

        }
      }

      return null;
    }
  }
}

using System; 

namespace com.michaelclarke.dynamic.api {
  public interface Module {
    String getText();
  }

}

Once you’ve got the two files you can compile them into a library….

api $ mcs -t:library Module.cs ModuleManager.cs
api $ ls -a | grep .dll
Module.dll
api $

Now that we’ve made the API the next thing to write is the application that is going to use it for loading modules. This is a very simple application…

using System;
using com.michaelclarkeblog.dynamic.api;

namespace com.michaelclarkeblog.dynamic.application {

  public class Application {

    public static void Main(String[] args) {

      if (args.Length > 0 ) {

        Module module = ModuleManager.getInstance(args[0]);
        Console.WriteLine(module.getText());

      } else {

        Console.WriteLine("Usage: mono Application module_name");

      }
    }
  }
}

Now we can compile our ‘Application’ against the API…

application $ mcs -reference:../api/Module.dll Application.cs
application $ ls -la | grep exe
-rwxr-xr-x 1 michaelfclarke michaelfclarke 3072 Apr  5 19:32 Application.exe
application $

And now finally we can write a couple of modules!

using System;
using com.michaelclarkeblog.dynamic.api;

namespace com.michaelclarkeblog.dynamic.modules {
  public class Mike : Module {
    public String getText() {
      return "Hello from Mike's Module!";
    }
  }
}

using System;
using com.michaelclarkeblog.dynamic.api;

namespace com.michaelclarkeblog.dynamic.modules {
  public class Another : Module {
    public String getText() {
      return "Hello from Another Module!";
    }
  }
}

Compile the modules…

modules $ mcs -t:library -reference:../api/Module.dll Another.cs
modules $ mcs -t:library -reference:../api/Module.dll Mike.cs
modules $ ls -la | grep dll
-rwxr-xr-x 1 michaelfclarke michaelfclarke 3072 Apr  5 19:36 Another.dll
-rwxr-xr-x 1 michaelfclarke michaelfclarke 3072 Apr  5 19:36 Mike.dll
modules $

There is just one last thing we need to do before we can run our application. We need to copy the Module.dll API from the api directory into the application directory…

modules $ cd ../application
application $ cp ../api/Module.dll .

And now lets try running our dynamic application…

application $ mono Application.exe ../modules/Mike.dll
Hello from Mike's Module!

application $ mono Application.exe ../modules/Another.dll
Hello from Another Module!

application $ mono Application.exe
Usage: mono Application module_name