Hello All,
My name is Andre Garzia and I live in Brazil. I am one of the summer of code students that will be working with Haiku. My project is the Network Preferences Application. I do most of my work on macs, most of my work is related to custom servers or web apps. I have a hobby which is to collect operating systems and machines and network them all. Right now I have couple macs (both classic and mac os x), linux, solaris, zeta, haiku, windows mobile, newtons and a magic cap machine, all networked, so I’ve felt the pain and joy of configuring different kinds of machines with different needs.
Who would have thought that something like me being chosen as a student for GSoC would actually happen. But it did. Blissfully indeed.
Anyway, designing a good user interface is not as easy as it seems. The truth is, not even for a second did I think it was, really. On my project road map, I’ve set designing the installer UI as my first task. Following the discussions with the Usability Team, a satisfactory concept came to life.
This article contains outdated information, please read with caution. Mainly in the second half of the last year the Haiku USB stack has matured a great deal. Not only has it stabilized a bit, it has also seen the addition of an EHCI driver to support USB 2.0 devices. A rewritten UHCI driver and a new implementation of the USBKit library are other steps to a complete stack. The reason to write about that is the following: An increasing number of people apparently get interested in the progress of Haiku USB and they start to ask questions about the completeness and usability of the stack.
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.
I said it already, but I’m going to say it a million of times, I’ve never EVER would expected to work on such a project for the Google Summer of Code, I actually didn’t even think I would get in the soc. But anyway, here I am… so let’s begin!
Last night after I got bored reading the Kernel Kit section of the Be Book (it was about threads and related functions), I opened my shell and I dived right into the USB stack code.
Quick Updates
r20100-r20200
- Updates to Mesa 6.5.2 and binutils 2.17
- Consoled debugging of app server, input server and the registrar
- CPU initialisation fixes
- Introduction of the UserlandFS
Quick Updates
20000-20100
- Addition of class screensavers
- Customisable CFLAGS
- Useful URI to application redirects
- Syscall benchmarks and results
Quick Updates
19900-20000
- Introduction of USBKit reimplementation
- Interesting local message passing optimisations
- VMWare vmdk tools
- vmdk image generator
- vmdk jam target: haiku-vmware-image
Quick Updates
r19800-r19900
- Beginnings of AHCI support
- Hardware cache flush for SCSI
- Stability fixes for the USB stack
- Port of the following filesystems
Quick Updates
r19700-r19800
- Addition of fortunes, including Haiku specific texts.
- Tweaked thread scheduler.
- Many VM enhancements and fixes
- Addition of resource editing tool, resedit.
- Addition of VMware graphics driver.
