Blogs

the last quarter term is mostly spent on acpi cpuidle driver implementation. I also spent about 2 days to adjust the cpuidle framework so that the cpuidle generic module is loaded by lowlevel cpuidle driver, while the later will be loaded during boot up either by bus enumeration or calling get_module() manually. I also tested the power after acpi cpuidle driver is finished. The result is as good as intel native one. Since all the goals defined in my proposal are achieved, so the project is successfully finished.

Here I want to summarize the status:
generic cpuidle
generic cpuidle module is implemented which can be used on all cpu architectures;
x86 cpuidle driver
On x86 platform, we support intel native cpuidle driver and acpi cpuidle driver. The previous one make fully use of intel mwait extension support on intel newer cpus such snb, ivb or latter, since it won't touch the complex acpi part, it's preferred if the HW supports. The acpi driver is our last choice.
power saving number
On my T420 laptop, it saves about ~2.5watt
main limitation
we don't support old platform which doesn't have ARAT(always running apic timer). To support such platform, we need to enhance haiku's timer subsystem

I'd like to continue all the related power saving work in haiku such as to find and remove all the unnecessary wakeup source, to enchance haiku's timer subsystem mentioned above. I may also work on some acpi related driver, the acpi is complex but I learned a lot about acpi during this summer ;)

Finally I'd like to thank tqh for his guidance, carefully code review and kind help about ACPI related topics, thank haiku for giving me the chance to code for such a clean and beautiful operating system. I also owe a great deal to many haiku experts for their immediate answers on IRC or great suggestions on mail-list. The last thank belong to Google :D

Since three quarter term I've added NFS-level support for named attributes what means that virtually all important NFS version 4 feature are now implemented, as I described them in my blog posts during the coding period. What still needs to be done is to improve support of Haiku's extended attributes and a lot of bugfixing. There is also a room for performance improvement and several possibilities to organize code in a better way.

With the announcement of Ingo and Oliver's contracts for package management, it is worthwhile to revisit how package management will function. When reading, keep in mind that this explanation will be condensed, simplified, and partially incomplete. Nonetheless, it will provide a general overview on how things will work.

For this period, I have been working on getting resizing to work from within Haiku, rather than just in bfs_shell. In its current state, the code works, sometimes, if you don't stress it too much and write data to the partition while resizing. On the bright side, recovery from various errors is working well :). In terms of functionality, the only thing missing is the ability to grow full or almost full file system. The problem with this is that we need to grow the bitmap that tracks allocated blocks before we can actually make use of the new blocks. This can be overcome with a little slyness, but it's a bit of work, and adds some complexity.

I think it would be better to focus on getting the current code into a finished state. So my plan for the remaining time is to try to exterminate the remaining bugs, and polish the code. I'd also like to rebase my work into a neat patch set. The chances of finding time to add resize support to DriveSetup seem fairly slim at the moment. But since the task is independent of my other work, it might be something to start on if I run out of things to do in the last few days.

On a different note, I will be travelling away for two weeks at the end of the coding period (on the 18th), returning the September 2nd. Last time I went to an internet café my email account was hijacked, so I'll probably be accessing the internet sparingly. I hope this won't cause any trouble.