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.
I’ve recently been working on caching in NFSv4 client. It was essential in order to allow the client to be comfortably used. I can gladly say that the traffic generated by NFS client has been greatly reduced, thanks to metadata, directory, lookup and file caching. I’ve also implemented support for open delegations which, though not always available, allow the client to perform virtually all file operations without immediate server participation.
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.
Since midterm I have been working on the jsound port, which provides audio, MIDI input/output and the ability to control mixer volume and other parameters.
After getting my head around some of the media kit concepts the implementation has gone smoothly. I implemented audio output support first, as I guessed this would be the most used component. It works well. Then I implemented MIDI input and output support. This is untested so far because I don’t have any MIDI hardware.
I began to implement the acpi cpuidle driver so that the power saving feature can benefit all x86 platforms(In theory although). The acpi is more complicated than I thought. The main time is spent on implementing “_CST” evaluation and decoding.
First of all, to evaluate any acpi object/method needs acpi handle. Since haiku doesn’t export AcpiWalkSpace method of acpica, so after system booting, I can get the acpi processor handle. the only solution is using the device manager so that the acpi cpuidle driver can be loaded during boot.
I have continued to make good progress since my midterm report. All the kernel functionality except for user debugging is implemented, and I have ported a basic set of drivers, including PCI, disk drivers, BFS and PS/2 input. For most drivers, porting is just a matter of fixing compiler warnings. For some, there are 64-bit issues which make porting more difficult. For example, the USB stack will require a bit more work as it currently assumes that addr_t is 32-bit everywhere.
I have also made some progress in porting userland to x86_64. I currently have libroot, libbe, bash, and most of the command line utilities ported. I have got an interactive bash shell running on top of consoled (which is usually used to run gdb on if app_server crashes).
Last week Olivier and I had the difficult task of handling the booth at RMLL and showing off Haiku in the land of gruyère, chocolate and banks.
Over the weekend, Google processed the results for the midterm evaluations for Google Summer of Code 2012. I’m pleased to announce that all five students passed their midterm evaluations! As you may have seen, the students have been posting details on their progress and future plans on their blogs. Last month, two students even gained commit access. Alex Smith received it for Haiku’s repository and Hamish Morrison received access to OpenJDK.
After my quarter term report I worked on various bugs in the AWT port reported by testers, such as keyboard input problems. I also began reading up on the media kit in preparation for the next part of my project: the jsound port. This will bring audio and MIDI functionality to the OpenJDK port. Over the last week I made a start on the implementation for PCM input/output.
A lot of things have happened since the last status update! As far as I
can tell, the kernel part of the file system resizer is mostly complete.
Some details remain, along with a healthy dose of bugs to be fixed. In
addition, I've written a 'resizefs' command for bfs_shell. Let's look at
a typical session with the mighty resizefs!
fssh:/> resizefs 100
File system information:
Bitmap: 1 blocks (was 1)
Log start: block 2 (was 2)
Log length: 512 blocks (was 512)
Block size: 2048 bytes
Error: Not enough space left.
Status: Invalid argument
