From http://kt.linuxcare.com/latest.epl of 2/3/2000, here is an example of the Linux API changing and generally fucking over those who develop commercial software for it.

  • Block Device Interface Change And Related Pain
  • 2000/01/07 - 2000/01/11 (52 posts): [ANNOUNCE] block device interfaces changes

    Alexander Viro announced that the block device interface would be changing, and that some of these changes had made it into 2.3.38; he listed:

    Richard B. Johnson picked himself up off the floor and said:

    There were a number of replies to this. Alexander found Richard's post clueless and Monty-Pythonesque. On a serious (though annoyed) note, he explained, "one of the worst things about block drivers-to-kernel interface is that they share it with files. I.e. _any_ change in file_operations or in struct file or in struct inode and you are deep in it. Change the size of any field prior to ->i_dev and you are in for recompile. Change <gasp> device number bitness and even recompile may be of little help. Removing those dependencies (not all of them are removed yet, more will follow) is going to save _your_ ass a year later."

    Also replying to Richard, Victor Khimenko said, "Drivers MUST be changed with new kernel release (and thus via development branch: development kernels are just snapshots of development process after all). It was true from the start and it'll be true tomorrow. It's true for most OSes available. It's ESPECIALLY true for Linux where drivers are linked directly in kernel. If you expected something other then you made wrong choice choosing Linux."

    Gregory Maxwell said to Richard:

    Rik van Riel put it this way to Richard:

    But David Parsons objected to Rik, "Except, of course, that when the changes go in they are never backed out so the interfaces remain stable for the production kernels. That's the *really* annoying thing about this line of argument; when else should someone complain that an interface has been turned into gravel? If you wait until the development tree has become a production tree, enough code will be modified to work with the New! And! Improved! interfaces that your complaints (cf: old-style fcntl locking) will be dismissed sight unseen by the Core Team." He added, "The big support providers are the ones who benefit from interface churning. It's the small shops that get bitten in the ass because they don't have enough money to buy programmers or enough time to do the patches." There was no reply to this.

    Alan also replied to Richard with the quote of the day, saying, "Linux isnt at war. War involves large numbers of people making losing decisions that harm each other in a vain attempt to lose last. Linux is about winning."

    At some point, Richard posted again, having received many private emails in addition to the slew on the list. He said:

    Chris Adams and Horst von Brand suggested that "current distribution" refered to even-numbered minor version numbers only. Horst expanded, "OK, "current distribution" means 2.2.x kernel today, and was 2.0 sometime back. It will be 2.4 in a few months time, and perhaps 2.6 in a year and a half. You are supposed to distribute the machine and source to drivers &c _when shipped_, I'd assume. Check the code, test it to breaking *and keep it*. Ship that to customers, and either offer upgrades to 2.4 if needed for some reason, or stay put."

    Elsewhere, replying to Richard's original post, Jamie Lokier said, "If you need a stable API, you chose the wrong operating system. It's no secret that Linux APIs change. You can't blame the kernel developers for doing exactly what they said they will do. If you want, you can blame the people who incorrectly assumed the APIs would stay the same, for not investigating the obvious." And Ted added, "If you told your management that Linux kernel interfaces never change across versions, then you were sadly mistaken. However, the mistake is on your end, I'm afraid."

    To this, Richard replied:

    This time it was Alexander's turn to pick himself up off the floor; and in response to the first paragraph of Richard's post, said, "Oh. My. God. They are requiring you to do WHAT??? Do you mean that you really ship 2.3.x to your customers? Arrggh. "Source" == "source of what we are shipping". And not "anything that was written by other guys who started from the same source". It's utter nonsense. _No_ license can oblige you to include the modifications done by somebody else. Otherwise you'ld have those drivers in the main tree, BTW - _that_ much should be clear even for your LD." But David Lang put in, "he is not saying that he has to ship a 2.3 kernel, he is reacting to the fact that he will have to ship a 2.4 kernel. the blame for this lies squarly on the legal department who decided that they had to ship a "current" disto. There is some semblance of reason for this as they want to try and limit the support costs by not using "obsolete" versions, but given the way many of the major distros patch the kernel before shipping it you still may have problems. The answer is to figure out some way to educate the legal department to allow for a more gradual change."


    Vi Powered Lynx Now! Powered by FreeBSD
    Wed Jan 14 04:08:50 PST 2004   linux/breakage.src
    Updated: Sun Jul 28 2002 22:00.47   Viewed: never

    Copyright © 1998-1999 by Nick Johnson. All rights reserved.