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

Know your code

[prestwich]

So the really important thing is to really look through your code first - you need to:

1) Check it is all really your code - you didn't buy any in 5 years ago? If you have a source code control system then actually being able to trace your code is great.
2) Read the comments - ok, so lots of closed source contains rather dodgy comments that you might not want to be public.
3) Check that releasing it wouldn't be revealing any information you got under NDA from any of your suppliers/partners.

Re:Know your code

[prestwich]

Oh - when I was talking about dodgy I didn't mean swearing (I don't care about those); I meant things about for example:
1) Other employees
2) Your boss
3) Your customers

I've seen some classic example of these.

Place to Ask

[norm_z]

You could find more information at LKML. The archives are here, http://marc.theaimsgroup.com/?l=linux-kernel.

Many vendors have been moving from proprietary to open source. You can join LKML at http://www.kernel.org/.

Patience

[Z00L00K]

is necessary. It may be a good idea to first check that the code you have works with the latest versions of the Linux kernels, 2.6 firsthand and possibly 2.4. If there are too much problems supporting both, go for 2.6 and try to avoid pitfalls regarding deprecated functions. (use udev instead of devfs for example)

Include reasonable amount of documentation, like a README and an INSTALL file. Keep both short.

Try to use autoconf scripts, since that may help in the long run when people tries to build it on all kinds of strange platforms. Be clear of which platforms that are supported, and which are not. Be also clear of platforms known not to work.

Set up a bug report tool. Bugzilla is a well-known tool. Bugs will be reported, and you may also get fix feedbacks that way.

A clear versioning strategy is also necessary. Avoid a multitude of branches if possible. The preferred way is to have a public read-only CVS archive. (you can use cvsup to create a mirror of the real archive in case you have a security breach on the public server.)

Have a reasonable licensing for your software, it will pay off in the end. You may want to take a look at MySQL. Try to be flexible and not too complicated.

This seems to be what I could come up with on a short notice.

And GOOD LUCK!

*cough*

[Geekboy(Wizard)]

OpenBSD is striving to open up all drivers, and refuses to allow binary modules. Currently, they are targeting Adaptec, trying to get the management interface opened up. We don't want them to write code for us, or to support it, we just want docs, so *we* can write the code, and support it.

http://undeadly.org/cgi?action=article&sid=2005031 8231311&mode=expanded

Re:If it is not broken...

[kiore]

Because hardware has a bad tendancy to hang around long after the vendors lose interest in it?

By making the drivers open source & letting the OS supplier recompile them for new releases they lessen the future load on their support desk from people complaining that their Linux 2.8 binary drivers won't work in Linux 4.2

Re:codingstyle

[diegocgteleline.es]

Along with the coding style (Documentation/CodingStyle), I'd recommend also reading Documentation/SubmittingDrivers

Work with the community

[hellgate]

I am the maintainer of a driver in mainline Linux. An competing driver is offered by the actual hardware vendor (also Open Source). While working with their engineers has been quite pleasant, we have never been able to agree to work on the same driver.

So the people who know the hardware best are paid to work on a driver that few people use. Meanwhile, the driver in mainline keeps up with the frequent changes of in-kernel APIs but lacks the resources to make use of all the features the hardware offers.

A few companies (e.g. Intel with their eepro) seem to get it right: Have someone work with the community to write and maintain a driver in mainline. You are still largely in control as long as you are competent, and you are pushing the code people actually use.

Release tokens

[LP_Tux]

Make sure you tag each release with a tag appropriate to its stability (prealpha, alpha, beta, stable etc.) Also you might want to do what redhat did with fedora and have a section if the team working on the drivers in an open source manner. naturally keep the binaries available for download too. And make sure it compiles on GCC and mingw. Good Luck!

Re:codingstyle

[bheading]

There are good arguments in favour of keeping your file sizes down, eg to something like 10K, and splitting your functions over several files. The big one being turnaround time; if you have a multiprocessor machine your parallel builds can compile all the parts in parallel. Also if you make a change to a function in one of the files the compiler only needs to recompile that file and not your entire driver.

Obviously though there are reasonable constraints to this.

Re:Open source is more than Linux

[RWerp]

NVIDIA explained many times why it does not open-source its drivers. There are NDA issues involved.

Re:2 space tab indents?

[El Cubano]

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.

From "Code Complete":

Indentation has been shown to be correlated with increased programmer comprehension. The artcile "Program Indentation and Comprehensibility" reported that several studies found correlations between indentation and improved comprehension (Miaria et al. 1983). Subjects scored 20 to 30 percent higher on a test of comprehension when programs had a two-to-four-spaces indentation scheme than they did when programs had no indentation at all.

The same study found that it was important to neither under-emphasize nor over-emphasize a program's logical structure. The lower comprehension scores were achieved on programs that were not indented at all. The second lowest were achieved on programs that used six-space indentation. The studey concluded that two-to-four-space indentation was optimal. Interestingly, many subjects in the experiment felt that the six-space indentation was easier to use than the smaller indentations, even though their scores were lower. That's probably because six-space indentation looks pleasing. Bet regardless of how pretty it looks, six-space indentation turns out to be less readable. This is an example of a collision between aesthetic appeal and readbility.

The moral of the story is that even if you think it looks nice, it can impact the ability of people to understand the code. In an open source project where you want people to contribute, you need to lower the barrier as much as possible to ensure that there is a larger pool of potential contributors.

Re:Uh, this is a driver!

[Antique Geekmeister]

Right. And autoconf has nice structures to test for things like kernel versions, the presence of any specific libraries, GCC versions which can affect code compilation, the presence of x86 or ppc or x86_64 or ia64 hardware, etc., etc., etc.

It even has nice structures for building one version of a kernel module that's not the one you're running at the moment, or building RPM or .deb installation packages. But hey, if you want to write magical mystery Makefiles and #ifdef statements to deduce what the person doing the compilation actually wanted to do, go for it. Have fun re-inventing the wheel for every single program you write.