2010-11-29

USB for HelenOS

Because I am also member of the team that wants to add support for USB to HelenOS and I have enough of programming, I decided to write few paragraphs about HelenOS/USB project...

Disclaimer: text below is not an opinion of the whole team and shall not be taken literally. I am trying to make this post at least a bit fun to read ;-).

We are adding support for USB devices to HelenOS as a part of Software project subject and we officially started this month.

Because we just started, there is not much progress to report. Actually, we had first meeting several months ago, but it takes some time from first thoughts to written specification approved by the Software project committee.

However, we weren't refining the specification all the time. We were studying ahead the USB specifications to which our "product" must comply. Have you ever seen a USB specification? If no, then believe me that you have missed nothing. USB specifications consists of thousands of pages written in technical English by someone (actually, these specifications are always work of a group because solitary person would go crazy from writing it) with apparently no sense of humor. Not talking about different formatting conventions used in individual specifications.

Because of the huge scope of USB, our project goal is limited to USB 1.1 only and we are supposed to create a functional driver for USB keyboard (the official specification talks about HID keyboard but we all hope that it does not mean that we need to implement the whole HID specification which is very long and includes support for such items as gloves for virtual reality software). Also, priority is a static configuration (i.e. no hot unplug).

So, to sum it up, at the end we want to present HelenOS as an OS that is usable with keyboard attached by USB wire. This sounds that it is not much but because HelenOS has no support for USB at all, we are actually starting at zero and want to end with something that both developer and ordinary user can appreciate (well, for HelenOS, these are identical but that is not the point).

But back to our progress I promised to inform you about. In three words, "we are fighting". With what? Luckily, so far, not among ourselves. But there are couple of things we need to get familiar with.

First, we are fighting with Bazaar: it is something different that Git or Mercurial and the worst thing is different terminology and different command naming.

Next, we are fighting with HelenOS itself. It is simply different system than Unix or Windows and getting used to it needs some time. The difference includes the microkernel design in general, asynchronous IPC or fibrils. Plus limited functionality of libraries.

And, of course, we need to unify our coding styles and start writing according to the conventions used in HelenOS. Currently, we are in the phase so common among programming enthusiasts (after all, why we have HelenOS ;-)?): "I do not want to read this (ugly) code, I can do it better by myself" and "my coding style supersedes everything written so far in this file". In this, I am the "enforcer" because I am already past that phase. I had to fight with that months ago when I started working on NUMA ;-).

We decided to use the device driver framework and currently we are fighting with it as well. I believe that using the DDF is a good step in general although right now we are a bit confused. I guess we all expected that it would do more (and that we would not need to touch it at all). We already encountered some problems that might be bugs in DDF. Or maybe we only botched-up something on our side. As soon as we find out where the problem actually is and if it is really in DDF, we will report to the mailing list.

Okay, I hear you ;-). You want to know whether we actually wrote some code or we are only grunting and swearing. So here is our "coding" progress.

We have a very simple mini-framework for creating virtual USB devices to allow testing USB drivers. Currently, it pretends work of host controller with single hub and plugged-in keyboard.

We are now working on generic framework (built above DDF) for creating host controller and hub drivers that will first operate above the virtual host controller. Other efforts, running in parallel, are implementation of UHCI driver and keyboard driver with fixed (i.e. built into the source code, not read dynamically) descriptors. If you have no idea what descriptors I mean, lucky you. Descriptors are way how USB device for human input informs the host about the items it reports (e.g. whether it reports pressed keys or joystick button status or finger bend) and are very generic and the specification is simply awful (I guess it is in English by used prepositions but I am not 100% sure).

And last success is that we are getting used to having "programming sessions" each week where we meet and code together (and we are even having fun there).

And that's all. I hope I haven't omitted something and haven't insulted anyone. I will try to inform about our progress regularly. If this source is not enough (or you simply don't like my style of writing or whatever), you can follow our activities at our Trac...

2 komentáře:

  1. Thanks a lot for the update!

    Notes on Bazaar:
    - In my experience Bazaar is quite similar to Mercurial and uses similar commands. The only big difference is that with Bazaar you always have exactly one head per repository.

    Notes on device driver framework:
    - Considering we haven't ported any device or bus drivers to it (apart from those implemented as part of Lenka's thesis) and we haven't familiarized ourselves with it yet, there will most likely be issues that will need to be addressed.
    - My impression so far is that the device driver framework does *much more* than it should. We will definitely need to discuss it thoroughly.

    Notes on USB descriptors:
    - A USB bus has multi-level addressing (device, interface, endpoint) similar to PCI (device, function) or TCP/IP (address, protocol, port). The device address space thus exhibits a tree structure. A descriptor is just a node in the device topology tree. There's nothing to be scared of.

    OdpovědětVymazat
  2. Hi, thanks for the comments.

    The Bazaar and DDF complains shall not be taken too seriously, though. With Bazaar, we just need to get used to it and with DDF we must accept the fact that we are the first intrepid users of it ;-) and some things may not work on the first try (personally, I hope it will prove to be usable and become integral part of HelenOS).

    I guess we actually find two bugs in DDF so far and I will report it as soon as I am sure about it and, hopefully, after creating patches.
    BTW, what is the thing DDF shall not be doing?

    With the descriptors, I mixed up descriptors and HID reports. And I am scared of the HID report because of its complexity (luckily, I am not the one doing the item parser). The concept of tree structure with descriptors is clear to me, but funny thing is that I understood this tree topology better from sidenote-like picture in HID specification than from a chapter in main USB specification.

    OdpovědětVymazat