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. ..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. [EMAIL PROTECTED]) 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
Re: [ANNOUNCE] block device interfaces changes
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 <[EMAIL PROTECTED]> > To: Richard B. Johnson <[EMAIL PROTECTED]> > Cc: Theodore Y. Ts'o <[EMAIL PROTECTED]>, [EMAIL PROTECTED], > [EMAIL PROTECTED], Richard Gooch <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > 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, &
Re: [ANNOUNCE] block device interfaces changes
Richard B. Johnson wrote: > 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. There /is/ no single "current" distribution. *A* current distribution is of your choice, and there are quite a few with stable APIs, based on 2.2 kernels. Red Hat to name a random one. Have a nice day. -- Jamie
Re: [ANNOUNCE] block device interfaces changes
On Sun, Jan 09, 2000 at 08:07:38PM -0500, Richard B. Johnson wrote: > 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. Cobalt's lawyers seem to disagree with yours. IANAL, but I really don't see what they base this idea on in the GPL.
Re: [ANNOUNCE] block device interfaces changes
Alexander Viro wrote: * Inodes got a new field: i_bdev. Filesystems should not worry > about it - just remember to call init_special_inode() when you are > initializing device/fifo/socket in-core inode (in foo_read_inode() or in > foo_mknod(); all filesystems in the tree are doing it now). When you say inodes, do you mean in ram or on disk or both? Adding fields to the already bloated inode structure is (generally) not a good thing. It makes use of files for small objects less effective, which affects the applicability of filesystems to new applications like web search engine indexes. Why do you need it, I am curious? I do not mean to be discouraging of someone cleaning up old datastructures and making them better I just want to understand the change. Is the intent to get rid of i_rdev and replace it with i_bdev? Hans -- Get Linux (http://www.kernel.org) plus ReiserFS (http://devlinux.org/namesys). If you sell an OS or internet appliance, buy a port of ReiserFS! If you need customizations and industrial grade support, we sell them.
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. Ummm Richard, as far as I know the GPL requirement only means that you are obliged the source code to whatever version you _shipped_ , not whatever version the customer can possibly obtain from CVS or ftp (or Linus). So, for example, you are free to take Linux 1.2.13, write device drivers for it and provide (to your customers) a third cdrom with source. Of course someone might want a newer Linux release, but that is another issue. I think that "make it work with the very latest kernel" approach if fundamentally wrong. What if one of the new kernels has a bug ? Are you supposed to work around it and then write code again when it is fixed ? I would suggest picking a reasonably stable development kernel, write your drivers for it and then upgrade when sufficiently many chagnes are introduced. This way when new even series appears you already have drivers working with it. In no event you should be shipping development kernels to your customers. Vladimir Dergachev > > This seemed, by them, to be an easy solution to possible problems. > Unfortunately, for Engineering, this means that we have to keep everything > "current" during development so that, by the time equipment is shipped, it > will run with the "current" distribution (whatever this is). > > 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. > > 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! > > That said, a major problem with changes that I see, is that the changes > are made without the notion of a terminating condition. For instance, > new parameters are being passed to existing interface functions. > > If you are going to break an interface, you should plan on only breaking > it once rather than opening the door for more changes and leaving it > open. For instance, once you have to pass more than (depends upon the > machine) about 3 parameters, it's best to put them all in a parameter- > list (structure) and pass only the address of the parameter list > (pointer). > > >From that time on, you only have to add structure members to the parameter > list if you have to add changes. If I had seen these kinds of changes > I would not have complained. It means I have to rework stuff only once. > > So `read(f,...)` should have been changed to `read(params *)` and > you are done with it forever as long as you don't change structure member > names and functions for kicks. > > Cheers, > Dick Johnson > > Penguin : Linux version 2.3.36 on an i686 machine (400.59 BogoMips). > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ >
Re: [ANNOUNCE] block device interfaces changes
- Original Message - From: "Richard B. Johnson" <[EMAIL PROTECTED]> > 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. Your legal people are idiots...You must make available the source of what you ship. > This seemed, by them, to be an easy solution to possible problems. Ah the crux of the problem...legal people invent problems for a living. What could they possibly have been thinking? > Unfortunately, for Engineering, this means that we have to keep everything > "current" during development so that, by the time equipment is shipped, it > will run with the "current" distribution (whatever this is). Too bad you rolled over on this. Would have been better to duke it out with legal right up front. On a constructive note...maybe you could try telling legal that it's risky and irresponsible to to ship developmental kernel code with little testing and you should stick to stable production sources. "Current" doesn't mean pre-production. good luck, jeff
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. ..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. [EMAIL PROTECTED]) 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?
Re: [ANNOUNCE] block device interfaces changes
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. This seemed, by them, to be an easy solution to possible problems. Unfortunately, for Engineering, this means that we have to keep everything "current" during development so that, by the time equipment is shipped, it will run with the "current" distribution (whatever this is). 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. 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! That said, a major problem with changes that I see, is that the changes are made without the notion of a terminating condition. For instance, new parameters are being passed to existing interface functions. If you are going to break an interface, you should plan on only breaking it once rather than opening the door for more changes and leaving it open. For instance, once you have to pass more than (depends upon the machine) about 3 parameters, it's best to put them all in a parameter- list (structure) and pass only the address of the parameter list (pointer). >From that time on, you only have to add structure members to the parameter list if you have to add changes. If I had seen these kinds of changes I would not have complained. It means I have to rework stuff only once. So `read(f,...)` should have been changed to `read(params *)` and you are done with it forever as long as you don't change structure member names and functions for kicks. Cheers, Dick Johnson Penguin : Linux version 2.3.36 on an i686 machine (400.59 BogoMips).
Re: [ANNOUNCE] block device interfaces changes
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. - Ted
Re: [ANNOUNCE] block device interfaces changes
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. Someone misrepresented Linux to management, eh? I'm not surprised you're getting flak. If management know what they got into by approving Linux, you should be paid for your work. If they don't, someone misrepresented Linux and that doesn't do you any good in the long run. The kernel developers have always been clear that the core APIs change from time to time, especially in the development branch. They have therefore represented Linux accurately. > Once you claim to have a "Professional Operating System", > its development must be handled in a professional way. You didn't know what you were really buying into when you started using Linux? I'm absolutely /sure/ the kernel developers have made it clear: the APIs will change from time to time. It has never been secret. You should not be surprised. > If major kernel interface components continue to change, Linux is in a > heap of trouble as are most all of those who are trying to incorporate > it into new designs. If you need a stable API, you chose the wrong operating system. It's no secret that Linux APIs change. You can't blame the kernel developers for doing exactly what they said they will do. If you want, you can blame the people who incorrectly assumed the APIs would stay the same, for not investigating the obvious. An all cases you should be paid for your work unless you were the one who told management "let's use Linux, the APIs will not be a problem". have a nice day, -- Jamie
Re: [ANNOUNCE] block device interfaces changes
"Richard B. Johnson" wrote: > > On Fri, 7 Jan 2000, Alexander Viro wrote: > > > Folks, there are changes underway in block device interface and > > some of them made it into 2.3.38. > [SNIP...] > > Good grief Charley Brown! You, in a few key-strokes, just blew away > major portions of the work done over the past few years by software > engineers who ported their drivers to Linux. Linux will never be > accepted as a 'professional' operating system if this continues. > > It's enough of a problem putting one's job on-the-line convincing > management to risk new product development to Linux. Once these > products are in Production, and bugs are discovered in the OS, > we must be able to get the latest version of the OS and have our > drivers compile. If this is not possible, you do not have an > operating system that is anything other than an interesting > experiment. > > 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. Why didn't you just stick with the old kernel then? Simple solution to existence problems for coder: Never change a running team. > Industry is at war. You can't do this stuff to the only weapons > we have. Once you claim to have a "Professional Operating System", > its development must be handled in a professional way. If major > kernel interface components continue to change, Linux is in > a heap of trouble as are most all of those who are trying to > incorporate it into new designs. The problem is that many of the intefaces you are talking about are in a bad need for a change. -- Marcin Dalecki
Re: [ANNOUNCE] block device interfaces changes
On Sun, 9 Jan 2000, Richard B. Johnson wrote: > The industrial use of Linux is not at the desktop. Industrial use of Linux usually doesn't involve the kernels which are marked as `development', ie. where the `middle' version number is odd and where major things are expected to change. People venturing out on that terrain can know what they're heading into (see http://kt.linuxcare.com/) and shouldn't come whining when some actual development happens in the development branch of the kernel. The should only whine when development stops, not when useful changes are taking place... cheers, Rik -- The Internet is not a network of computers. It is a network of people. That is its real strength.
Re: [ANNOUNCE] block device interfaces changes
Alan Cox wrote: > > Linux isnt at war. War involves large numbers of people making losing decisions > that harm each other in a vain attempt to lose last. Linux is about winning. Wonderful!!! (wrt Linux but too better wrt war) Can I cite that? ;-) -- Abramo Bagnara mailto:[EMAIL PROTECTED] Opera Unica Via Emilia Interna, 140 Phone: +39.0546.656023 48014 Castel Bolognese (RA) - Italy Fax: +39.0546.656023 ALSA project ishttp://www.alsa-project.org sponsored by SuSE Linuxhttp://www.suse.com It sounds good!
Re: [ANNOUNCE] block device interfaces changes
On Sat, 8 Jan 2000, Richard B. Johnson wrote: > Good grief Charley Brown! You, in a few key-strokes, just blew away > major portions of the work done over the past few years by software > engineers who ported their drivers to Linux. Linux will never be > accepted as a 'professional' operating system if this continues. [snip] We all know your position on compability. :) Many people, including myself, usually understand and agree with it. However, you are going a little far on this one. The change is going into 2.3.x, and that *IS* the approiate place to break interfaces. These kinds of changes should certantly not be introduced into 2.2.x. This should cause you little difficulity, as your example of having to upgrade to fix a bug should not apply. When you upgade to fix a bug then you should just be increasing patchlevel. If there is not a patch for a bug in 2.2.x which is fixed in 2.4.x then there is a bug in the Linux development process. In order to move forward, we *must* break things. To make up for this we continue to maintain old versions. There are still bugfixes being made against 2.0.x and there will be bugfixes against 2.2.x. RedHat even still issues updates against RH4.2.. So if this were to have occured within a stable kernel version, or if it had severly affected userspace, I would agree. Do you really need to complain about this?
Re: [ANNOUNCE] block device interfaces changes
In <[EMAIL PROTECTED]> Richard B. Johnson ([EMAIL PROTECTED]) wrote: > On Fri, 7 Jan 2000, Alexander Viro wrote: >> Folks, there are changes underway in block device interface and >> some of them made it into 2.3.38. > [SNIP...] > Good grief Charley Brown! You, in a few key-strokes, just blew away > major portions of the work done over the past few years by software > engineers who ported their drivers to Linux. "Major portions" ? Are you joking ??? > Linux will never be accepted as a 'professional' operating system if this > continues. Why you think kernel developers should think about this ? It's task for RedHat, Caldera, SuSE management NOT for Linus, Cox, Viro or Arcangeli. > It's enough of a problem putting one's job on-the-line convincing > management to risk new product development to Linux. Once these > products are in Production, and bugs are discovered in the OS, > we must be able to get the latest version of the OS and have our > drivers compile. WHY ??? It's not possible with Windows, it's not possible with Solaris, why it should be possible with Linux ? > If this is not possible, you do not have an operating system that is > anything other than an interesting experiment. Ok. So we do not have any OS that is anything other than an interesting experiment. > For instance, there was a simple new change in the type of > an object passed to poll and friends. In 2.2 or in 2.3 ?? > 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. > Industry is at war. You can't do this stuff to the only weapons > we have. Why not ? Why Microsoft can do this, Sun can do this and Linus can not ??? What's the difference ? > Once you claim to have a "Professional Operating System", > its development must be handled in a professional way. If major > kernel interface components continue to change, Linux is in > a heap of trouble as are most all of those who are trying to > incorporate it into new designs. But if such components will be continue to change then Linux is in even bigger heap of trouble since this will mean that you can not fix design errors ! > The industrial use of Linux is not at the desktop. It involves > writing drivers for obscure things like machine controllers > (read telescope controllers), Digital signal processors (read > medical imaging processors), and other stuff you can't buy at the > computer store. It doesn't matter if you fix all of Donald Becker's > drivers to interface with the new kernel internals. You have still > broken most everything that counts. Drivers MUST be changed with new kernel release (and thus via development branch: development kernels are just snapshots of development process after all). It was true from the start and it'll be true tomorrow. It's true for most OSes available. It's ESPECIALLY true for Linux where drivers are linked directly in kernel. If you expected something other then you made wrong choice choosing Linux.
Re: [ANNOUNCE] block device interfaces changes
On Sat, 8 Jan 2000, Richard B. Johnson wrote: > On Fri, 7 Jan 2000, Alexander Viro wrote: > > > Folks, there are changes underway in block device interface and > > some of them made it into 2.3.38. > [SNIP...] > > Good grief Charley Brown! You, in a few key-strokes, just blew away > major portions of the work done over the past few years by software > engineers who ported their drivers to Linux. Linux will never be > accepted as a 'professional' operating system if this continues. Imminent death of Linux is predicted; GIFs at 11... > It's enough of a problem putting one's job on-the-line convincing > management to risk new product development to Linux. Once these [snip "they will fire my ass if they'll know"] You know, considering the level of clue you've demonstrated... > Industry is at war. Really? > You can't do this stuff to the only weapons > we have. Paging Monty Python... Paging Monty Python... > Once you claim to have a "Professional Operating System", > its development must be handled in a professional way. If major > kernel interface components continue to change, Linux is in > a heap of trouble as are most all of those who are trying to > incorporate it into new designs. > The industrial use of Linux is not at the desktop. It involves > writing drivers for obscure things like machine controllers > (read telescope controllers), Digital signal processors (read > medical imaging processors), and other stuff you can't buy at the > computer store. It doesn't matter if you fix all of Donald Becker's > drivers to interface with the new kernel internals. You have still > broken most everything that counts. Like your ability to read? FYI: one of the worst things about block drivers-to-kernel interface is that they share it with files. I.e. _any_ change in file_operations or in struct file or in struct inode and you are deep in it. Change the size of any field prior to ->i_dev and you are in for recompile. Change device number bitness and even recompile may be of little help. Removing those dependencies (not all of them are removed yet, more will follow) is going to save _your_ ass a year later. Said that, if your position includes the kernel work and you can't tell Becker's drivers from the block devices... I'm not sure that your ass is worth saving. And if you are going to use block devices for DSP - you ought to start looking for new job. Preferably in a different field.
Re: [ANNOUNCE] block device interfaces changes
> Good grief Charley Brown! You, in a few key-strokes, just blew away > major portions of the work done over the past few years by software > engineers who ported their drivers to Linux. Linux will never be > accepted as a 'professional' operating system if this continues. Hardly. You obviously didnt look at what the patch changes in the driver interface. > 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. Better hope your boss doesnt read linux-kernel > Industry is at war. You can't do this stuff to the only weapons Linux isnt at war. War involves large numbers of people making losing decisions that harm each other in a vain attempt to lose last. Linux is about winning.
Re: [ANNOUNCE] block device interfaces changes
On Fri, 7 Jan 2000, Alexander Viro wrote: > Folks, there are changes underway in block device interface and > some of them made it into 2.3.38. [SNIP...] Good grief Charley Brown! You, in a few key-strokes, just blew away major portions of the work done over the past few years by software engineers who ported their drivers to Linux. Linux will never be accepted as a 'professional' operating system if this continues. It's enough of a problem putting one's job on-the-line convincing management to risk new product development to Linux. Once these products are in Production, and bugs are discovered in the OS, we must be able to get the latest version of the OS and have our drivers compile. If this is not possible, you do not have an operating system that is anything other than an interesting experiment. 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. Industry is at war. You can't do this stuff to the only weapons we have. Once you claim to have a "Professional Operating System", its development must be handled in a professional way. If major kernel interface components continue to change, Linux is in a heap of trouble as are most all of those who are trying to incorporate it into new designs. The industrial use of Linux is not at the desktop. It involves writing drivers for obscure things like machine controllers (read telescope controllers), Digital signal processors (read medical imaging processors), and other stuff you can't buy at the computer store. It doesn't matter if you fix all of Donald Becker's drivers to interface with the new kernel internals. You have still broken most everything that counts. Cheers, Dick Johnson Penguin : Linux version 2.3.36 on an i686 machine (400.59 BogoMips).
[ANNOUNCE] block device interfaces changes
Folks, there are changes underway in block device interface and
some of them made it into 2.3.38.
* New type (struct block_device) is defined. We have a cache of
such objects, indexed by dev_t. struct block_device * is going to replace
kdev_t for block devices. Handling of the cache is done in fs/block_dev.c
* They have methods (struct block_device_operations). Currently
the set is { open, release, ioctl, revalidate, check_media_change }. For
now (and it's going to change) types are the same as in file_operations.
However, in the near future they are going to become
int (*open)(struct block_device *bdev, mode_t mode, unsigned flags);
int (*release)(struct block_device *bdev);
int (*ioctl)(struct block_device *bdev, unsigned cmd, unsigned
long arg);
int (*revalidate)(struct block_device *bdev);
int (*check_media_change)(struct block_device *bdev);
* ->revalidate() and ->check_media_change() disappeared from
file_operations.
* register_blkdev() takes block_device_operations instead of
file_operations now. For one thing, it means that block devices are more
or less insulated from all future changes in file_operations (Good
Thing(tm)). For another, it means that drivers should be modified. I did
the change for all drivers in the main tree, see the patch for details.
It's pretty easy.
* blkdev_open() doesn't change ->f_op. def_blk_fops has all needed
methods (open, release and ioctl call the methods from block_device_operations,
indeed).
* Inodes got a new field: i_bdev. Filesystems should not worry
about it - just remember to call init_special_inode() when you are
initializing device/fifo/socket in-core inode (in foo_read_inode() or in
foo_mknod(); all filesystems in the tree are doing it now).
Contents of this field: pointer to struct block_device if it is a
block device inode, NULL otherwise.
* Superblocks got a new field: s_bdev. Handled by code in
fs/super.c, points to the struct block_device if the mount is
device-backed, NULL otherwise (i.e. for NFS, CODA, procfs, etc.).
* do_mount() first argument is struct block_device * now. It does
the right thing for non-device mounts - just pass NULL and it will work
(allocate the anonymous device, etc.)
* Instead of calling get_blkfops(), use ->bd_op in struct
block_device. Moreover, better use blkdev_get()/blkdev_put()/ioctl_by_bdev()
(see examples in mm/swapfile.c, drivers/char/raw.c, fs/super.c,
fs/isofs/inode.c, fs/udf/lowlevel.c).
* Thing that is probably going to happen RSN: instead of struct
gendisk per major we may want to go for struct gendisk per _disk_. It
would mean that at some point near ->open() we will put the pointer to it
into the struct block_device. One obvious consequence being that
partitions-related ioctls() will become completely generic.
Notice that it is _not_ the same as devfs (and not a beginning of
moving devfs into the main tree). It just provides the backplane - no
namespace, no nothing. Inodes (either in normal filesystems or in devfs)
point to such animals. That's it. Eventually things like ->b_dev,
->b_rdev, ->i_dev, ->rq_dev, etc. are going to become pointers to such
objects, but it will be done step-by-step - otherwise we'll end up with a
moby patch and moby breakage in bargain...
Character devices are not affected at all - IMO using the same
type both for block and character device was a mistake. So their handling
remains as-is. Probably something should be done for them too, but that's
completely different story.
Cheers,
Al
