[lkml]   [2000]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.


> 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
on 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>
having TXT record with URL and kernel version(s) in the body). Then all
you need is (a) standard address (e.g. 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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:55    [W:0.287 / U:0.016 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site