Messages in this thread | | | Date | Tue, 11 Jan 2000 01:22:15 -0700 | From | Richard Gooch <> | Subject | Re: [ANNOUNCE] block device interfaces changes |
| |
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/
| |