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 so that
you can build the system now using (for example) redhat 6.1 and when you
ship the product you ship it with redhat 6.1 kernel 2.2.x, even if redhat
7.9 kernel 2.4.x is out by then, after you upgrade your driver to match
the 2.4 kernels you can then decide if you want to go to the trouble of
upgrading.
As an example 3ilinux is starting to sell a linux based appliance (embeded
system construction) that is starting to ship jan 2000 and is based on
redhat 5.2, they are working to upgrade to a newer kernel and when they do
they will start shipping something else. In the Solaris world there are a
LOT of drivers/firewalls/etc that will not work on 2.7 and so I have ~20
suns runnint 2.6 as that is the latest that is supported, this is not a
linux only problem.
David Lang
On Sun, 9 Jan 2000, Alexander
Viro wrote:
> Date: Sun, 9 Jan 2000 21:52:59 -0500 (EST)
> From: Alexander Viro <viro@math.psu.edu>
> To: Richard B. Johnson <root@chaos.analogic.com>
> Cc: Theodore Y. Ts'o <tytso@MIT.EDU>, linux-kernel@vger.rutgers.edu,
> linux-fsdevel@vger.rutgers.edu, Richard Gooch <rgooch@ras.ucalgary.ca>,
> Andries.Brouwer@cwi.nl
> 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/
>
-
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/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:16 EST