Git commit: aa205b0d6b511e989af68d07794859dac6829be3
Back after a long week with not much activity. I am commited to finish this last mini-project, consisting of getting Xen to work under gPXE, using multiboot.
After yesterday's meeting it has been decided that an extra imgdecode command would make matters unnecessarily complicated for the end user. Therefore, decoding will be done automatically after an image is fetched. If users want to avoid this behaviour, the imgfetch command will have an –nodecode flag.
I implemented the necessary modifications today, along with gzip header parsing. If things go well, tomorrow I will decompress the first image using gPXE. After that, I will focus on getting Xen to work.
Git commit: 9436fefddae93ad660784f030aa95523b70dfb68
Ported the decoding code today from the zlib library, but I didn't get to test it or arrange it properly. I am curious of the impact of calling copy_to/from_user for every byte. I'll probably have to rethink that part alltogether.
Git commit: bfee6adeaa089b26f5b2ddcf684c961978889a08
Argh. Not a good day. Spent most of it chasing a silly bug. Stefan suggested that we should use the ISIZE field from the gzip trailer so we allocate all of the buffer in advance so we don't keep calling realloc. I did that, got the length from the field but I still had the original image's length in the malloc() call. Needless to say that I exceeded its bound and weird stuff started happening. Eventually I solved this and everything was fine.
The code is still a mess, but it works. Tomorrow I'll remove unnecessary comments and rearrange it a bit.
Git commit: 17e0dcec786d5d223d7cac173d70117984bb5009
Cleaned the decoder code and fixed an memcpy issue which I suspect came from the fact that the source and destination fields were overlapping. Note to self: also try memmove. This still needs some work, but I am anxious to get to the Xen part and make it work, so I'll start working on that tomorrow.
me.away()
Today I wanted to create a basic Xen setup so I started browsing the Internet for information. After finding several sites I set out to compile the hypervisor from source and found some pre-built dom0 images. At first I struggled with getting the GRUB 2 menu entries correct since there have been some changes since GRUB legacy. Some of these changes affect multiboot images (such as Xen), so I should keep this in mind when I end up making changes. Eventuall I got to a point where the hypervisor booted, but the dom0 kernel had problems in finding the root partition. I'll dig into this tomorrow.
I fixed yesterday's root partition issue by getting a new kernel and generating a new initrd. It booted, but unfortunately the keyboard does not work X| Teh horror.