It’s been a bit since my last status update, so I guess it is time for another one.
First of all, I’d like to inform you that I received the first half HCD payment. Since it’s a (fantastic) community based effort project, I thought you wanted to know where your donations ended up.
As of commit r27159 you should be able to read data from an UDF partition. The module has not yet been added back to the image, as I’d like to do some more tests, but as far as I can tell, the port of UDF to the new FS API is close to complete, and you can start testing by adding the module to the image and trying using DVD formatted with UDF, or iso image made with mkisofs.
Time for a quick update.
As with r26676, a first buggy xsi semaphore implementation is now present in Haiku (buggy because there is another patch waiting to be reviewed and commited that fixes some issues, but there might be some more coming).
It is now possible to download, compile and run the file system benchmark suite bonnie++. The version I've used is 1.03d, which has been suggested by the author of the suite. With this suite it is possible to test the file system implementation, plus the way Haiku works under low memory and heavy I/O operations.
It’s been almost a month already since the very first Haiku Code Drive began!
First of all thanks to all of those who have voted me, I was very surprised about the poll result.
Now some updates about my project.
As you know, my project aims to test the stability of the bfs file system. In order to do so the idea is to first implement XSI Posix semaphores, and then compile bonnie++ which is a benchmark suite for file systems.
During this summer I had the chance to improve myself, and work on the USB isochronous support of HAIKU. I wrote some code for every layer of the HAIKU USB stack: USBKit library, usb_raw driver, usb bus manager and most of all the uhci driver. I also spent/waisted some weeks with the usb_webcam media addon, but sadly with not success. Anyway here is what I did.
UHCI driver: Basically I added all the necessary code to handle isochronous transfer in both direction (in and out).
Just to keep those of you interested updated, after discussing it with both my mentor and Michael Lotz, and after a very quick chat with Francois Revol, I am going to add isochronous support to both the USBKit and usb_raw driver. Meanwhile Francois, if time is on his side, should add isochronous support to his user space quickcam driver (see src/add-ons/media/media-add-ons/usb_webcam/). This way I can test my previous patches and perhaps everyone can start using his logitech quickcam with Haiku by using codycam.
For those of you who are not following the haiku-commit mailing list, I’ve added the isochronous support to the UHCI driver. I’m working on a quickcam driver to test the code, but if someone of you out there, already have some very simply driver, that needs isochronous support, please contact me and help me with the testing.
The sooner I’m done with the testing, the sooner I’ll move on to the OHCI driver.
Actually is more than half. This quick post is just to inform you that I wrote the part that schedule an isochronous request in the UHCI driver. I’ve already sent the patch to Michael for his review. The only part that is missing is the code that remove the request once it has been processed or canceled, which is not as trivial as I thought.
As many of you know, I’ve started working even before the SoC started officially. I’ve already sent two patches to both my mentor (Oliver R. Dorantes) and Michael Lotz for review. One of them has already been commited by mmu_man (thanks). The second one is under review. With this latest one, the usb stack manager should be complete, as the QueueIsochronous method has been implemented, along with the CalculateBandwidth. My next move is to implement the UHCI isochronous method.
After reading the main part of the USB specs, I moved on to the UHCI driver specs this week-end. I can now say, that implementing the isochronous part to the UHCI driver is a lot easier than I thought, and I guess Micheal can confirm. While reading the UHCI specs I followed Micheal’s code, and I have some questions about it, but I’ll write him an email for that. By the way, is R1 intended only for x86?
I’ve been reading some more code and I’m getting more confident with it.
Basically data transfer is done with memcpy.
In the ehci controller, registers are mapped every time a controller is found. This is done in the controller constructor.
As the ehci specs says: Register Space. Implementation-specific parameters and capabilities, plus operational control and status registers. This space, normally referred to as I/O space, must be implemented as memory-mapped I/O space.
