gsoc

NFSv4 client: midterm report

Blog post by Paweł Dziepak on Wed, 2012-07-11 16:58

Having implemented mandatory hooks by quarter term I had good base for implementing other operations like write, rename, create, etc. Moreover, improvements in file system migration and user ID mapping. Apart from that, file locks required most work, since they are both more complicated than other NFS operations and Haiku VFS originally did not allow the file system to handle them its own way.

cpuidle: midterm report

Blog post by yongcong on Wed, 2012-07-11 13:04

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...

x86_64 port: midterm report

Blog post by xyzzy on Wed, 2012-07-11 11:08

Since my quarter term report I have made a great deal of progress. The boot loader x86_64 support is finished, and the kernel can now be booted to the point of searching for the boot volume. A screenshot of this:

BFS Partition Resizer: Quarter Term Report

Blog post by ahenriksson on Mon, 2012-06-25 10:58

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).

NFSv4 client: quarter term report

Blog post by Paweł Dziepak on Sun, 2012-06-24 18:09

I have already implemented all mandatory hooks (and several others), what means that NFSv4 client now allows to browse directories and read files on remote filesystems. Last several days I spent on improving the existing code and supporting some less usual NFSv4 describes, that includes reclaiming share reservations, support for server migration and volatile filehandles. I also needed to deal with NFSv4 that do not provide file's inode number, that was solved only partially since proper workaround will be much easier to implement when file metadata and directory contents are cached.

cpuidle: quarter term report

Blog post by yongcong on Fri, 2012-06-22 15:42

I completed my 1/4 goal ahead of proposal schedule. By the original plan, I should investigate whether we need necessary changes to x86 idle routine and x86 architecture specific instruction usage. The results were reported to gsoc maillist on 3rd Jun. Here are the copied results:
1. no need to change x86 idle routine
2. monitor/mwait works perfectly. I have measured the power consumption when using idle implemented with "monitor/mwait", it's the same as the version implemented with "hlt".

x86_64 port: quarter term report

Blog post by xyzzy on Fri, 2012-06-22 12:27

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.

Syndicate content