Was it something I said?

I saw that OpenBSD 4.7 was released a couple of weeks ago.  I tried to help, I really did.

I used to have a fanless 600MHz VIA system with a cheapie Airlink 101 Wi-Fi card that I used as a home wireless router.  I ran OpenBSD on it for a few reasons — at the time I started, the OpenBSD wireless stack was ahead of Linux; their security obsession appealed to me; and not using Linux everywhere seemed like a fun thing to do.  It all worked pretty well, except that the wireless interface sometimes got stuck while forwarding heavy traffic.  For quite a while, I survived with hacks similar to this nutty crontab entry.

Eventually, though, I said to myself, “Self, you’re a kernel hacker.  You should be able to fix this driver.”  And indeed, after a couple of evenings of hacking, I figured out what was wrong and came up with a patch that improved things immensely for me.  The problem was that the driver was not written with a system as slow as mine in mind, and it got confused if more than one interrupt happened before it got a chance to service the first interrupt — you can read the patch description for full details.  Of course, being a good free software citizen, I sent my patch to the OpenBSD mailing lists so that it could be applied upstream.

Here’s where things went wrong.  I never heard from the author of this driver — I got no reply when I reported the original bug, and no replies to any mail I sent about my patch.  I did get several reports from other users who had the same problem and found that my patch fixed things for them as well, and finally another OpenBSD committer wrote, “Then if no one objects I’ll commit it tomorrow.”  Unfortunately, at this point the original driver author did seem to get interested — he sent private email to this committer (not copying the mailing list or me) objecting, and so we ended up with, “Objections were made. Apparently this patch only works for AP and does funky stuff to the hardware. So back to the drawing board on this one.”  As I said, all of my attempts to work directly with the driver author to find out what those objections were or how to improve the patch were ignored.

At this point I gave up on getting my patch upstream (and when I upgraded my wireless to 802.11n, I chose a MIPS box running OpenWrt).

7 Responses to “Was it something I said?”

  1. LGB says:

    Yes it seems many OpenBSD developers’ ego is a bit too much, not a single word from them _until_ you want to do/doubt/etc their code … 🙁

  2. JamesP says:

    Welcome to the dark side of free software

    And even though this is rarer in linux, it happens a lot

    “does funky thing” seems to me to mean “this is my driver, don’t mess with it even if you’re right”

    • roland says:

      @JamesP: Actually I don’t think the same thing could happen in Linux. If I had a patch that was ignored by a maintainer for months, I think sending it to Andrew Morton along with an explanation as detailed as the one I provided for my ral patch would end up with it getting merged. And I think that would actually work even if I weren’t a known kernel hacker. In the OpenBSD case, I actually did get email from Theo, but his answer was that only the driver owner could commit my patch.

  3. Darrin Chandler says:

    Sometimes a patch works great without exception on your system, but doesn’t work well everywhere. Without knowing details I would guess this to be the case here. Hard to tell.

    One thing I would suggest for this kind of patch is to submit a bug report using sendbug. Include how to reproduce the problem as well as the patch. The nice thing about that is there’s a ticket created, so if the dev think “yeah, I’ll get back to that” and forgets then someone will prod him about the open ticket some time. Honest.

    • roland says:

      @Darrin: I don’t necessarily expect my patch to be committed as-is. However, take a look at the original patch I linked to. I tried to describe the underlying bug in a good amount of detail, and really if you think about the interrupt handling of the driver, the bug is pretty obvious. The problem I have with the whole thing is that the “owner” of this driver never replied to any of my public postings or private emails where I described the bug, proposed a solution and asked for guidance on how to proceed. His sole contribution was to NAK my patch for vague reasons (in private email that I wasn’t copied on) when another committer finally decided to commit it.

      Also take a look at bug 5958/kernel. I don’t think reporting this bug again is going to help when the developer of the ral driver has shown no interest in debugging this over the past few years.

  4. abadidea says:

    IMHO open source projects should NEVER make decisions based on private communications. Public list/blog/tracker or it didn’t happen.

  5. florian says:

    Roland, it *can* and does.

    I’m not sure, but I think I could still produce a mail where someone from the CGL project replied to me explaining why they (at the time that i.e. included a. cox) did work on memory hotplug and these, but didn’t get around to fixing the mess that pci hotplug in linux used to be (i am not aware of its current state). in short: the maintainer let them know to stay away from his code, period.

    which is kind of funny considering
    a) they were a bunch of kernel gurus, embedded gurus and telco professionals who had experience with such features
    b) pci hotplug being not very impressive back in 2005 due to it’s lack of “WORKING”
    SuSE back then actually had a flag in rc.config called pci_hotplug_do_real_hotplug

    in the same context there was a fun email from greg kh stating that multithreaded hw init cannot work and is not worth the effort or actually impossible to implement
    that was caused on his own findings on a not-large system and feedback from a few users that ran into problems with his implementation.

    back then we daily enjoyed multithreaded and background initialisation of hardware on our hp-ux boxes with no issues and extreme gains in bootup times – notably those have many dozes of cores, dimms and sometimes over 1000 visible luns.

    what i’m trying to say is: there are ego issues, most probably in almost all projects.
    half of the time people will try to push their own ideas without listening, and the other half of the times the other people will not listen to someone elses ideas.

    Did you happen to read the sociology study on the samba project?
    I think in OSS we need to learn to be more aware of how social factors influence our interactions…

    … so we can better concentrate on hacking and being anti-social 😉