Moving from Binary Drivers to Open Source?

GerryGilmore asks: "We are a division, specializing in telecommunications equipment, of a very large hardware manufacturer. Our equipment, DSP and PSTN boards, has been supported under Linux through a set of binary driver modules and binary libraries implementing our API set. We are in the process of migrating to a completely open source-based software infrastructure to be more in sync with the rest of the Linux industry. However, not having any real experience with moving from proprietary to an open source model, we wanted to see if the Slashdot crowd has any similar experiences to share: The Good; The Bad; The Ugly; and how best to avoid the most common pitfalls."

Comments

codingstyle

[pe1rxq]

Read the codingstyle document and look at what others are putting into the kernel!
The biggest mistake is some idiot using unusual function names, spreading his driver over atleast ten files and using 2 character indents or no indentation at all.
Especially if your source is ported from windows (or the programmer has only windows experience) make sure you do this right.

Jeroen

Open source is more than Linux

[Anne Thwacks]

Remember, once the source is in the open, people can port your stuff to *BSD and WindRiver, VXworks, etc.

This may be really useful for sales, but it may also lead to a serious amount of bug finding!

Are you really sure you want your device drivers debugged?

Some Linux kernel tips

[Wesley Felter]

Get into the official kernel. If a driver isn't in Linus's tree, it doesn't matter, so you will be on an endless treadmill of API breakage. Once your driver is in the official kernel tree, the kernel hackers will take responsibility for most of the API refactoring.

Know the politics. Most Linux kernel developers aren't accountable to anyone and don't negotiate. You will have to put up with whatever requirements they give you if you want your code to be part of the kernel.

Know the effort. You will probably be asked to rewrite your drivers, possibly more than once. This will take months. If you don't do it, then open-sourcing the drivers was mostly wasted effort.

As others mentioned, coding style is important. Also, wrappers are not allowed in the kernel, so call kernel APIs directly instead of wrapping them. The result is a totally Linux-specific driver, but the rules are the rules (see above).

Re:2 space tab indents?

[rohanl]

The problem with using tabs is that although they work fine for indenting code, they do not work well for continuation lines.

Consider the following simple example, coded with spaces and 2 character indent.

public class Foo {
void methodName(int arg1, int arg2,
int arg3, int arg4) {
return;
}
}

Now suppose, I had used tabs instead. With 2 character tabs, it would look the same.

But, someone else who prefers 4 character tabs, opens the source in their editor, and gets:

public class Foo {
void methodName(int arg1, int arg2,
int arg3, int arg4) {
return;
}
}

If you're going to standardise on using tabs for indentation, you need to distinguish between indentation and alignment and use tabs for indentation and spaces for alignment

So in my exmaple, you would need to write:

public class Foo {
<tab>void methodName(int arg1, int arg2,
<tab>________________int arg3, int arg4) {
<tab><tab>return;
<tab>}
}

It's hard enough sometimes to get programmers to follow coding standards where the difference is visible to them, but trying to enforce a mixture of tabs and spaces like this when the editor does not make it easy to differentiate between them is almost impossible.

It's much easier to just standardise on spaces everywhere.