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?

2 space tab indents?

[reborn]

Interesting, a study we did showed that in terms of productivity and readability 2 space tab indents was optimimum. "Why?" I hear you ask - any developer that's worked on a project of any size above "tiny" will know that large indents don't aid readibility, unless your code is very 'squished'. Which brings us onto one of the most important aspects of any project - white space.

Let's look at the following chunks of code;

Many would write a simple for-loop like this (using standard 8-space unexpanded tabs);

for(int l=0;l10;++l){
printf("%d\n",l);
}

versus the more experienced coder (using 2 space expanded tabs);

for ( int l = 0; l 10; ++l )
{
printf ( "%d\n", l );
}

Maybe it's just my opinion (and many others on projects I've worked on), but the second is far more readable and when a new coder comes along to maintain the code she/he would have a much easier job going through the code to figure out how it works. You may not believe me, but take any large chunk of code you may have and take the time to space it out and re-indent it - I guarantee that any decent coder will see my argument is correct.

Re:2 space tab indents?

[Beatlebum]

The point of using the tab character is it does not represent a fixed indent. If you like 2 char indents, set your tabs to 2; if you want 8, set it to 8.

Using hard coded spaces consumes more bytes and requires reformatting to change the indent. Use of Tabs is a no-brainer, but judging from the comments here and elsewhere people still don't understand the issue.

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.

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).