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?

Re:Open source is more than Linux

[imkonen]

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

It makes me wonder why more hardware manufacturers aren't asking this very question, and why anybody making new devices wouldn't open their driver code from the beginning. I mean if you make hardware, and you write software to run it on at least one platform, what is the point in making it hard for people to port the software to another platform? Isn't your profit margin in the sales of the hardware? Do you think you're going to have to drop the price of your hardware just because the software that would normally be included can also be obtained for free? I doubt it. People buying hardware assume software is included, but they're not going to care how much it cost to develop. Even if you're too cheap to hire a programmer for anything but Windows drivers, some cheapskate programmer out there somewhere is going to inherit/buy used from ebay a cheap printer/camera/firewall/whatever and decide it's worth his time to port your software to his platform. If he's kind enough to share it with the world...BOOM...now you have a new customer base for free. If the code is sloppy maybe you do a little cleaning up re-release it, or you don't actually promise to support the other OS.

The point to keeping the drivers closed I can think of is some fear about your competitors learning trade secrets, but it seems like in most cases, one would expect the breakthroughs to be in the hardware itself and not the code that runs it.

"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?"

As has already been pointed out, why would this be a bad thing? That's usually considered one of open source's selling points. It's not like the bugs weren't there before. It's just that now some of the bug reports might contain useful suggestions rather than a screaming office drone on a deadline pissed that the brand new printer didn't interface with their computers.

Dear Dialogic

[Anonymous Coward]

Thank you for your interest in finally removing your head from your posterior.

I would like to suggest the following:

- Communicate with your application developers openly. You rob yourself of invaluable feedback when the forums you sponsor are not as free as the source.

- Particiapte. While it's not neccessary to feed the trolls, your guidance and expertise are critical to the success of the project.

- Take a resolute approach. An insistance on silly extra clauses added to otherwise good licenses only curtails adoption. Be free, or don't bother.

Other telecom vendors do a better job....

[Anonymous Coward]

I am the CTO for a telecom company that once used hardware from this "very large supplier". Having worked with their products, I would be very surprised if the code for their drivers is not a train wreck. We struggled for over a year to get their PSTN boards to work with a generic ISDN PRI network.

We switched from this company to a smaller vendor that shipped PSTN and VoIP boards with stable drivers. We've never had a problem since, and will never go back to the previous vendor.

As for open source, if I am paying ten or twenty grand for telecom hardware, I expect the vendor to have developed and debugged their drivers. I am a customer. I am not their development team. So I could care less if the drivers are OSS or not if they work. If they don't work, I am going to buy hardware from another vendor.

Maybe I am cynical, but I suspect this company is looking at OSS as a way to dump more work on their customers.

Re:Other telecom vendors do a better job....

[GerryGilmore]

For whatever my word is worth, we're doing this for several reasons: 1) Sell more stuff. I am a greedy, capitalist pig and I want to sell more stuff. I know from having participated in the Linux industry since installation was on a pile of floppies that open source drivers allow hardware companies to sell more stuff. 2) Help our software be better. As mentioned above, I know that open source leads to better software, even if you do start with a train wreck. :-) 3) Help our customers. It's only somewhat altruistic in that I know that open source will help our customers in making their products better. By doing this, it helps me and my company. We are going to continue to own and maintain the code and, quite frankly, we are not anticipating much initial assistance. It's a long-term effort to work better with our customers so that they won't have similar horrible experiences as you, sadly, had.

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?

[vivian]

What about 4 space tabs? That's IMHO the best compromise between readability & vertical space use, and what I have been using for the last 12 years.

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

Two-way delivery

[captaineo]

As a developer of binary drivers you are used to having complete control over your code, and "pushing" all updates down-stream. But once your code goes in the kernel (which I highly recommend - don't let it languish outside Linus' tree), you'll have to consider how to deal with code changes coming TO you FROM the kernel developers.

This is both a good thing and a bad thing. It's good because you'll get fixes from people testing your code on all sorts of weird platforms you've never heard of. It's bad because you can wake up one morning and discover the kernel API for your type of driver has changed overnight, and your code won't even compile until you re-write half of it (there go your plans for the weekend). A certain amount of lag is acceptable, and you can restrict support to the stable kernel series only if you want, but expect to hear a lot of whining from users who will demand that you keep up with the cutting-edge development code.