As anticipated, I was able to do little more than set up my environment during the first stretch of GSOC and the last few weeks of school and my previous internship. I was able to find computer with a compatible network and graphics card, which should hopefully be faster than running Haiku on a virtual machine on my normal computer. I also successfully installed haikuporter, although I am having some trouble using it. I am also trying out an IRC account.
These weeks were prolific in terms of design and experiments but due to university commitments i am a bit late with the expected goals.
At this point i have an implementation of BContact / BRawContact and i’m working to get the VCard translator functional. In these hours my focus is the communication part between the raw contacts and translators.
One of the latest design decisions was to make BRawContact own a translator that is suitable for writing the format specified by the user, otherwise it will use the default B_CONTACT_FORMAT (a flattened BMessage) for the final file. The passage of the data between the object and the translator will be done every time the programmer want via the Commit() method. If a path is not passed, the BRawContact will be virtual and stored in memory.
On June 7, I turned in my dissertation and my semester ended. On June 10, I had my first final exam. Now it’s time to produce a progress report for Haiku. Almost miraculously, I’ve actually managed to squeeze some Haiku development time in and am making progress of a kind.
The most tangible progress is mostly in the form of debug messages and crashes into Kernel debug land, but I consider anything that I do which has a measurable effect to be progress. So far all my efforts are aimed at trying to understand how all the different pieces of a userland driver component come together. I’ve had a lot of help with this from my mentors and from people in IRC and on the haiku-development mailing list. Michael Lotz and Anevilyak (IRC nick, I don’t know a real name) were particularly helpful.
During the first quarter, I defined an interface language to use for creating the bindings. I had to create my own for several reasons. Probably the biggest factor was the need to know whether the target language has the right to destroy an object. Most of the target languages has some kind of automatic garbage collection; the programmer never needs to worry about whether to delete an object to free up memory. I didn’t want to force programmers to worry about it when they don’t normally need to. Therefore, I had to be able to mark whether an object was delete-able, so the generated bindings could delete it automatically if necessary.
In my last blog post, I mentioned the following goals:
- Define an interface definition language
- Define preliminary bindings for a minimal test programy
- Write a preliminary generator to create the bindings
- Write the minimal test program
These have now been achieved, and the minimal test program (in Perl) runs. It shows a window with a button, and the button label changes when the button is clicked.
It still has problems, of course. For example, after 32 messages pass through MessagesReceived, it dies. But it’s nice to see something actually running.
I was busy with finals throughout the Community Bonding period, which left me with little time to work on GSoC-related tasks. I still have 3 exams left with the last one being on June 7. That's when the fun starts. For now I'm merely playing with ZFS on FreeBSD on a virtual machine. I still need to make my way through at least the ZFS On-Disk Specification. Even though the information contained in this document is not strictly required for porting ZFS to Haiku, it's a useful read nonetheless. It also makes me look like a rockstar when I open it in coffee shops.
During the community bonding period, i have researched around the project to prepare my work for the coding days that will follow.
I also promised to talk with the other devs in the ml, it was not necessary in these days…i’m working with the help of Alex to a document describing the entire API in order to discuss it in the ml.
The first problem was to choose a Default Media Format for contact translators, my choice has been addressed to a flattened BMessage. BMessage will be used internally by BContact to represent the contact fields and the state of the object. BContact will be also a BArchivable object.
In the community bonding period I made some brief contacts with my two mentors and did some reading of specification for UVC devices as well as the header for the current USB kit. My mentors confirmed that the EHCI interface for isochronous transfers with USB devices is not working properly and does not have a good set of tests. Neither my camera nor my mentor’s camera are successfully engaged by Codycam at the moment. Fixing this fundamental connection issue is the first priority for the first quarter of the GSoC period, before moving on to working on the UVC driver.
Some of the clearly amazing things that got done during the community bonding period were:
I also discovered that Buildbot (Mostly its dependency: Twisted) don’t play nice on FreeBSD, the platform which currently builds Haiku nightlies on Matt Madia’s server. It’s not a huge priority to me at this point but it appears a bug still exists and will have to be filed (on my list).
During the community bonding period I played around with the existing guest additions patch, getting it to build and switching my repository over to git to preserve my sanity. I’ve learned a lot about the way Haiku drivers and modules work, especially in the last few days, and it seems that a few things are simpler than I originally thought they’d be and some things are more difficult.
As an example of the latter, it turns out that drivers can’t provide APIs to other drivers; only modules can do this. This posed a problem for the shared folders module, which needs to either be in a separate module or contain extreme hackiness. As a driver, the original vboxguest couldn’t allow vboxsf to use its API. To solve this, mmu_man and I decided that the best first task would be to break up the existing vboxguest driver into a module (vboxguest) containing the guest additions and a driver (vboxdev) which exposes the library to userspace as /dev/misc/vboxguest. This is now finished.
