gsoc2012

With the good preparation in quarter term/bonding period, I have completed the generic cpuidle kernel module, native intel cpuidle module and cpuidle driver(for states/info reporting). By original plan, these tasks will be all completed by the end of 3/4 term...

For the 1/4 term milestone, my goal was to have inode-moving working. This is mostly completed, you can view the code at http://web.student.chalmers.se/~andrhen/move_inode_v2.patch

For this period, I have the following things planned:

Allocation of new block positions: I have a good grasp of what needs to be done for this, and it's not a lot of work.

Moving file data: Last week I thought I had this nailed down, but it turned out to be a little more involved than that. Still, there has been some good progress made, and I'm sure it'll be completed within the period.

Doing the actual resizing: This step involves a few sub-steps: traversing the file system to move things out of the way, possibly moving the file system journal, resizing the block bitmap and updating the file system header. None of it should be that complicated (in theory), however it's likely that the more thorough exercising of the rest of the code will reveal problems with it.

Testing: I obviously test code as I write it, but I probably won't have time for a more rigorous approach in this period. I have a lot of time allocated for that in the next period, so it's not a disaster.

As it looks right now, things seem to be on track with the timeline in my proposal (which is actually not that great, as the timeline was a bit pessimistic).

As I mentioned in my first blog post, I had exams until a couple of weeks ago, so I didn't start working on my project properly until then. However, I am now working full time so I expect to make a lot more progress in the coming weeks.

So far I have made it possible to compile the kernel for x86_64 by adding stub implementations of all the architecture functions and fixing compilation errors/warnings (all architectures that Haiku supports at the moment are 32-bit, so there were various problems in the code when compiling for 64-bit). I have also made changes to the kernel_args structure (the structure which the bootloader passes to the kernel containing information such as the boot volume, loaded modules and the memory map). As I am making the x86 bootloader able to load both a 32-bit and 64-bit kernel, this structure must be compatible between both. The changes I have made make all members the same size regardless of whether compiling for 32-bit or 64-bit.

I have now begun implementing ELF64 loading into the bootloader so that the 64-bit kernel can be loaded. I expect to have the bootloader work completed by the end of next week, after which I will begin work on the kernel.

My GitHub repository can be found at https://github.com/xyzzy51/haiku/tree/x86_64 (I'm working in the x86_64 branch), for anyone who's interested in following my progress. You'll also see my commits on the haiku-commits list.

During community bonding period, apart from reading specifications, I also analyzed other NFSv4 client implementations, looking for interesting ideas and solutions. One thing I noticed which may be worth using in my NFSv4 client implementation is caching of some parts of generated RPC request.

In addition to that I also got more familiar with what Haiku expects from file system modules. I have written a very simple dummy file system and check how things work. The problem I encountered here is that Haiku when creating a vnode identifies the file using its inode number. NFSv4 server provides its clients inode numbers but does not provide any way to get file using its inode number. That is why the client will have to keep some cache of inode numbers it is aware of in order to map them to NFSv4 file handles. Self-balancing BST seems to be a good idea.

I started working a few days before May 21st and the day the official coding started I already had a module that was able to generate and send NFSv4 null request and receive a reply using either TCP or UDP as transport protocol. In the first weekend I polished that code, added proper error handling, interpret RPC errors that might happen, made the client use only one TCP connection or UDP socket per server no matter how many file systems are mounted and added support for AUTH_SYS authentication flavor. Public backup of my work is available here.

Since most of RPC and XDR code is complete (apart from few issues I need to address) my next goal is to write NFSv4 request generation and reply interpretation. That will allow me to start writing hooks a FS module should provide. According to my initial timeline I had to have all mandatory hooks written by June 25th. However, now I think there is a big chance I will have that done by June 11th (quarter term).