Then there are no point and case is closed, right? [LWN.net]

Then there are no point and case is closed, right?

Posted Aug 5, 2009 22:17 UTC (Wed) by mikov (subscriber, #33179)
In reply to: Then there are no point and case is closed, right? by khim
Parent article: A tempest in a tty pot

Sure. And we have many OSes which promised and failed to deliver that: Windows, Solaris, etc. It just does not work. Drivers from NT don't work in Windows 2000, drivers from Windows 2000 crash the Windows XP, drivers from Solaris 8 are unusabel in Solaris 10, etc.

Well, I am talking about a source level API, so I don't see your point really. Plus, I disagree with your example. The vast majority of drivers did work between Windows versions. Speaking both as a user and as an ex-Windows kernel developer.

What I do see is the wish to reduce number of problems for manufacturers by increasing number of problem for users and developers - and I can not agree that it's good idea.

I am sorry but you are dead wrong. Very ironically just today (about hald an hour ago) I encountered exactly the problem I am describing.

I was asked to troubleshoot a Debian Lenny image on a new batch of POS machines. Well, guess what, Lenny's kernel 2.6.26 does not support the network adapter (Intel 82567LM-3).

So, WTF am I supposed to do? All the "wisdom" against out-of-tree drivers and stable API expressed in the numerous responses does not help me a bit! Should I perhaps install a newer kernel version? Huh? What about security updates? Backport a driver from 2.6.28? I don't have time to do that, and I am not a network driver expert.

Fortunately for me, Intel maintains an out-of-tree driver at http://e1000.sf.net/ . An out of tree driver saved the day! As usual and as expected.

Unless somebody can offer me a better solution than this out-of-tree driver, I don't see how the arguments carry any weight.

(Log in to post comments)

Then there are no point and case is closed, right?

Posted Aug 9, 2009 11:46 UTC (Sun) by khim (subscriber, #9252) [Link]

Well, I am talking about a source level API, so I don't see your point really.

What makes API so much different from ABI? In my experience breakage occurs not at format ABI/API level, but at level of semantic: old driver presume that something is done in some specific way and it does not work in exactly this way after small fix in kernel (I've personally seed cases where driver stopped working with NP4SP5=>NT4SP6 and XPSP1=>XPSP2 upgrades) - at that point the only solution is some person who can maintain driver... and if you have such person why do you need stable ABI or API?

Plus, I disagree with your example.

How can you disagree with truth?

The vast majority of drivers did work between Windows versions.

The wast majority of drivers work with Linux out-of-the-box. Speaking as a Linux user.

I was asked to troubleshoot a Debian Lenny image on a new batch of POS machines. Well, guess what, Lenny's kernel 2.6.26 does not support the network adapter (Intel 82567LM-3).

How is it different from my example above - where Windows XP SP2 broke drivers for Pinnacle DV500?

So, WTF am I supposed to do?

You know the answer - you just refuse to resign yourself to it.

Should I perhaps install a newer kernel version?

Yes. Either that or ask your vendor for older motherboard.

What about security updates?

What about them? Latest version of kernel always have the latest version of security updates applied - it's up to your distribution to package them.

Remember that bug in driver can make your system volnerable (case to the point - and conveniently it's about e1000 as well) so there are only two ways to live:
1. Use drivers from your distribution kernel (and forgo latest and greatest hardware), or
2. Use latest and greatest version of kernel (and live with possible bugs).

Both approaches don't need any stable API or ABI...

P.S. Infromation from Windows campus agrees with me: substantial percentage of problems with the (in)famous Windows (un)stability are caused by drivers.