Contributed by maxime on from the usual-suspects-bus dept.
Jacob gives us some extra information about what kind of hardware he would like to hack on, and what kind of new features the users will get if they send it to him:From: Jacob Meuser
To: email@example.com Subject: CVS: cvs.openbsd.org: www Date: Wed, 3 Nov 2010 18:20:49 -0600 (MDT) CVSROOT: /cvs Module name: www Changes by: firstname.lastname@example.org 2010/11/03 18:20:49 Modified files: . : want.html Log message: I have enough usb audio devices, other devices would be useful though.
So, if you want to give some love to the USB support in OpenBSD, just contact Jacob and send him some new toys to hack on!At this point, I'm just trying to fix the bugs. Our USB stack is buggy. It's not documented, and different drivers handle similar situations quite differently. It's rather easy to crash a system by inserting and removing a device at just the right time. IMO, that's embarrassing for an OS that takes pride in stability and doing things "the right way". What I'm working on now is cleaning up and making more consistent what happens in USB drivers when they are attached/detached from the kernel. Since USB devices can be removed at any time, they may be removed while the device is in use, which can easily lead to a crash or hang if the driver tries to access the already removed hardware. There is surprisingly little protection against this in the current USB stack. My plan for this release cycle is to make it possible to add and remove any USB device at any time without hanging or crashing the system, and to start documenting the functions in the USB stack. Most of the USB devices I have are uaudio(4) and uvideo(4). I also have one umass(4), a few rum(4), some uhub(4), and USB mice and keyboards. While these devices use most of the features of the USB stack and allow me to test changes in a few cases, changes to the USB stack itself affect *all* USB devices. This is why I am asking for more USB devices. USB network devices are particularly useful because they often use timeout(9)s and the USB task thread. These allow the device to be used asynchronously. In other words, a task may be scheduled for later, but before the task is started or completed, the device can be removed, which can lead to problems. Of course, I am learning more about the USB stack in general while working on the attach/detach issues. Certainly there are other issues lurking, such as the crash on usb_allocmem() which has been reported recently on misc@ ... and of course we'll need support for USB 3.0 at some point.
(Comments are closed)