Sic Transit Gloria Laptopi

Posted May 14, 2008 21:49 UTC (Wed) by flewellyn (subscriber, #5047)
In reply to: Sic Transit Gloria Laptopi by mtall
Parent article: Sic Transit Gloria Laptopi

The first point is the major problem.  With open specs, problem 2 goes away (no need to
reverse engineer, there's a spec), problem 3 is handled automagically (in-kernel drivers are
updated when interfaces change), and problem 4 is irrelevant (no need to release drivers if
you have open specs).

Sic Transit Gloria Laptopi

Posted May 15, 2008 0:32 UTC (Thu) by mtall (guest, #52045) [Link] (1 responses)

The first point is the major problem. With open specs, problem 2 goes away

While it would be nice to have open specs for everything, in reality this isn't so simple. It is an uphill battle to convince company XYZ that open specs are better than trade secrets. Also, a company might be inclined to release drivers with only certain features enabled, for business reasons -- by giving open specs they are in effect giving up control of how their hardware is used (as Creative got upset with recently). Not that I am a fan of this type of "control", but that's real life for you.

problem 3 is handled automagically (in-kernel drivers are updated when interfaces change)

This "automagic" process is neither automatic nor magic: there is considerable economic cost involved. There is no tool that automatically converts a set of code to use a new API/ABI. Someone has to do this work manually, and this is not a trivial matter in terms of effort.

problem 4 is irrelevant

Someone still needs to write the driver -- either there's a highly inclined open source developer willing to work for the kick of it, or an open source developer getting paid to do it (e.g. via Red Hat, SuSE, etc), or the company which makes the hardware. I'd say the latter has more vested interest in getting their hardware used as widely as possible.

Open specs

Posted May 15, 2008 11:30 UTC (Thu) by man_ls (guest, #15091) [Link]

It is an uphill battle to convince company XYZ that open specs are better than trade secrets.

Companies don't have to release their trade secrets at all. Greg KH has started a project just for that task, so that hardware developers don't have to release specs if they don't want to. Sure, competitors will have the source code to the driver, but they have to reverse-engineer that too -- and while it is easier than with binaries, it is not automatic either.

IMHO, keeping trade secrets in the driver is not such a good idea; they can be reverse-engineered fairly easily. The most successful hardware devices conform to standards anyway, and those things that give Linux users the most grief (software suspend, power management, BIOS problems, graphic card modes) seem to be those that deviate from their respective standards.

This "automagic" process is neither automatic nor magic: there is considerable economic cost involved.

What flewellyn means is that once a driver is in the kernel, the hardware developer doesn't need to worry about it anymore: the kernel community will update it whenever it is necessary.

Someone still needs to write the driver

Again, the Linux Driver Project is willing to do exactly that. I believe this project is doing a great service to the kernel community, if only to remove a couple of sore points that can be used as excuses by hardware developers.