PLEASE TAKE ME OFF THE CC LIST.
BTW: I'm on holidays and won't be replying to email for a while.
Richard B. Johnson writes:
> On Sun, 9 Jan 2000, Alexander Viro wrote:
> [SNIPPED]
>
> > > 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?
> >
>
> Again, since there was so much mail on this, I will answer this one
> only with cc to linux-kernel.
>
> The idea is that once something gets "released", it gets built with
> whatever distribution is available at that time. That distribution is
> shipped (if required). It's just like DOS/Windows/SunOS/Solaris, etc.
> You ship with the "current" distribution. Certainly a customer would
> be really pissed to get a new product with a two-year-old version of
> software.
>
> Once the product is shipped, we can make "service-pack" updates just
> like everybody else, which are not free.
>
> What this means for us, is to keep our development software sufficiently
> up-to-date so that there are no radical changes required once a release
> is imminent. In no case do we intend to ship using "development"
> kernels. But, to keep up-to-date for a pending release we need to be
> using development kernels in engineering. I never attempt to use any
> of the "pre-NN" intermediate stuff anyway.
>
> A lot of people are going to have to do the same as Linux works its
> way from being just a desktop OS to something being used to replace
> Sun software and Windows in industrial applications. The embeded
> market doesn't have to worry about releases and version numbers
> because the customer usually couldn't "upgrade" anyway. I have
> a "platinum" project which uses some old stable version of Linux
> that I happen to like. It's an embedded system that runs VXI bus
> instruments. It works just fine. That kernel will never have to
> be changed, even if bugs are found. They can be fixed with the
> reset button.
>
> There are two major interfaces that are critical to success:
>
> (1) The POSIX/C-interface API.
> (2) The module API.
>
> Much care has been taken to assure that (1) stays stable. We need
> some such care on (2). In particular, if major changes are made,
> they should be terminating, i.e., made in such a way that they
> are unlikely to ever have to be made again.
>
> For example, open(), read(), write(), ioctl(), in the kernel
> seem to have originally been designed to emulate the structure
> of procedures named the same in the user-mode API. Then additional
> parameters needed to be passed to these procedures so they grew.
> Now, more parameters need to be passed. Maybe it's time to pass
> these procedures a single pointer.
>
> Drivers written for this new interface, or older drivers, once modified
> will forever never care if you add new structure members that they
> never access. New kernel, just recompile.
>
>
> Cheers,
> Dick Johnson
>
> Penguin : Linux version 2.3.36 on an i686 machine (400.59 BogoMips).
-- Regards,Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca
- 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:17 EST