wisermac
is an attempt of implementing multi-channel multi-radio mac in Linux for off-the-shelf 802.11 hardware. It's currently maintained by me.
code documentation
read the readme.txt in the code.
personal view how should this code be maintained (in a research group)
Code maintenance is always difficult in a research group when the code is passed from one person to another. There are several reasons. One is that the code often lacks documentation that is up to the industrial standard because we simply don't have that much time to document every thing. Another is that research code is often use some other open source (research) code which lacks documentation and evolves or becomes outdated pretty fast. Also people in research groups do not necessarily have the same coding background, and it's often the case that one only start to learn to code in a certain system when he needs to. And sometimes research code is so experimental that the coder himself can't fully explain why certain decisions are made. So, clearly, it's the understanding of the code, not the APIs that needs to be pass from one to another, and we have to do it in an agile way so we can still have fun. So what I propose is that the new maintainer should talk to the previous one, look at the code, and read the paper(yeah. we don't have documentation, but we have papers) to get a generally idea how this code works. And then, instead of trying to start tweaking the existing code immediately, one should try some extreme refactoring action: you recode the WHOLE thing yourself! Yes, I think that's the fastest way to really pass the code from one to another in research group, if we assume failure means infinite time is needed. But don't get me wrong here. I'm not encouraging you to throw away other people's hard work. What I'm proposing is to start from your own take on the idea, improve/learn iteratively. Use the existing code as a guide for learning in this process. One can only learn when one starts thinking on his own first. It might take a lot of effort at the beginning since you need to learn all the background about the system and the theory to even be able to code a hello world on your own. But that's exactly what you should do before you face the depth in the code, and by insisting starting from your own code you're forced to do things right, in the fastest way known to me. Starting from there, you learn and add feature incrementally, in iterations, and this will get faster and faster. In the end you code might end up very similar to the previous work, because that's the guide you have followed. But now the code has really become YOUR CODE, not SOMEONE ELSE'S CODE.
Good luck.
