Hmmm
June 25th, 2008 Michael ClarkeI don’t think this needs words…
I was reading a friends blog today and I saw he’s linked to a truly fascinating news article about Scientists who have managed to genetically modify bugs in such a way that they consume waste and produce crude oil.
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.
At last it has happened! I have been putting off writing my memory allocator for MouthOS for some time. Up to now I’ve been able to survive without one by simply not having any ‘undefined’ data structures - everything in the kernel was a known, static size.
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.
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.
Last night I started my new Sun blog at blogs.sun.com - http://blogs.sun.com/michaelfclarke. So, what does this mean for this blog? Well, nothing really. I’ll continue to update this blog as I have been doing, putting personal projects and the like up. What this does mean however is that you’ll now be able to track my progress as a Campus Ambassador Co-ordinator for the UK.
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.
You are currently browsing the Michael Clarke weblog archives for June, 2008.