Contributing to OpenBSD
homing-on-code.blogspot.com
homing-on-code.blogspot.com
Right now I'm contributing to Microsoft's coreclr trying to get it to build and run on FreeBSD, because I believe having a wide choice of software and software platforms will indirectly aid the project.
If a new project you see doesn't work on your platform, find out why and submit a patch containing your fixes. That will both make it easier for people coming along later and raise awareness of the platform amongst developers.
This is mainly done and abstracted in a module called the Platform Abstraction Layer (PAL), which everyone else then relies on.
So far the biggest amount of work has been getting in the FreeBSD-specific things, and correcting the codepaths which incorrectly has assumed that any Unix not Darwin/OSX will behave exactly like Linux.
You know, ensuring stuff like '#include "gnu/somelib.h"' doesn't get included where it shouldn't, replacing enums with ints here and there. Stuff like that.
Except for one component, I've yet needed to genuinely write lots of code. It's mostly been following the build-process and see what fails.
For errors I don't immediately see a resolution for, I've created issues and usually that has either been picked up by the .NET-team itself or they've provided me enough feedback to work it out myself.
When submitting small patches nothing special is needed, but for bigger patches you need to sign a "contributer agreement". Which is done all online, automatically and in a matter of mouse-clicks.
The .NET-team has really done a good job here, especially considering how they said "they were really new to this (OSS thing), so please bear with us" when this whole thing was first announced.
Edit: The mailing list thread has no results so far and suspects a use after free in the network driver? But.. gory details would be nice.
blog author here, like I mentioned in the blog post one of the developers suggested that it might just trigger a re-use of poisoned memory. OpenBSD (especially on snapshots) enables a lot of 'hostile' development features - poisoning freed memory is one of them. Some of those checks are disabled on releases in order to limit performance degradation. Why could dhcp impact a kernel panic? It boils down to the driver. If my understanding is correct the re0 driver works on the kernel level and uses the mbuf infrastructure for allocating and using memory on the kernel level. The specific memory usage pattern the re0 driver has might lead to the kernel or the driver reusing already freed memory. This is of course just a speculation I have based on the information I included in the blog post and received off list from one developer. It's not confirmed in any way and just an informed guess on the developers part. I think dhcp is just an easier way to trigger the panic as the OS does lock-up on this box when set to static IP even if dhcp was never fired even once (though I don't get dropped to ddb then).
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ic/re.c...