Messages in this thread | | | Date | Sun, 9 Jan 2000 21:52:59 -0500 (EST) | From | Alexander Viro <> | Subject | Re: [ANNOUNCE] block device interfaces changes |
| |
On Sun, 9 Jan 2000, Richard B. Johnson wrote:
> On Sun, 9 Jan 2000, Theodore Y. Ts'o wrote: > > > Richard B. Johnson wrote: > > > For instance, there was a simple new change in the type of > > > an object passed to poll and friends. This just cost me two > > > weeks of unpaid work! Unpaid because I had to hide it. If > > > anyone in Production Engineering had learned about this, the > > > stuff would have been thrown out, the MicroCreeps would have > > > settled in with "I told you so..", and at least three of us > > > would have lost our jobs. > > > > You had the choice of not upgrading to the latest kernel, didn't you? > > > > If it was you who chose to upgrade to the latest kernel, why are you > > complaining to us? > > > > 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. > > > > No. According to our Legal Department, to satisfy the GPL requirement > that we provide source to the end-user, they required that we supply a > "current" distribution of Linux if the end-user requests it.
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.
[snip]
> The obvious solution, given these constraints, is that we just ignore > all changes until shipping time, then attempt to compile with the latest > distribution, fixing all the problems at once. However, we then end up > shipping untested software which ends up being another problem. Checking > to see if it "runs" isn't testing software in the cold cruel world of > industry.
You do realize that stability of the system doesn't exceed that of the weakest link, don't you? You _are_ shipping untested software if you are shipping 2.3.whatever + your drivers. It's called unstable for a good reason. Ouch... OK, what if Linus will put a pre-patch-2.3.39-dont-even-think-of-using-it-anywhere-near-your-data-3.gz on ftp.kernel.org tomorrow? Will your LD require you to ship _that_? No? Is the notion of 'untested software' completely alien to them?
BTW, you could point them to Debian or RH - none of them ships the 2.3.x in released versions _and_ it's not even the latest 2.2.x existing. Hell, Debian 2.1 is shipped with 2.0 - switch to 2.2 is in potato (== Debian 2.2 to be). RH uses 2.2.12, AFAICS (with a lot of patches). And all of them have darn good reasons to do so - stability being the first one. Is there any chance to get your legal folks talking with RH lawyers? Or Caldera, or Corel ones...
> So, presently, I have 13 drivers I have to keep "current". Yesterday > they all got broken again. A week before, half of them were broken > because somebody didn't like a variable name!
Which might mean that repository of pointers to 3rd-party drivers (along with the contact info) might be Good Thing(tm).
I would suggest the following: keep this information in DNS (RBL-like scheme; i.e. <driver_name>.<author_or_company_name>.drivers.linux.org having TXT record with URL and kernel version(s) in the body). Then all you need is (a) standard address (e.g. update@drivers.linux.org) aliased to the script; (b) said script verifying (PGP, GPG, whatever) the source of mail and updating the record. IOW, all it really takes is somebody with nameserver, clue and decent connectivity. Any takers?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |