Messages in this thread |  | | | Subject | Re: kernel structures 2.0.29->2.0.30 | | From | Derek Atkins <> | | Date | 24 Apr 1997 17:21:35 -0400 |
| |
"David S. Miller" <davem@jenolan.rutgers.edu> writes:
> > Date: Thu, 24 Apr 1997 13:51:39 -0400 > From: Derek Atkins <warlord@MIT.EDU> > > I think this is COMPLETELY unacceptable for a _SUPPOSEDLY_ stable > release. > > There are cases where serious performance problems, bugs, and security > holes need to change these structures in order to do the fix at all. > There are some vendors out there who will try to not do the fix just > to keep all the third part vendor drivers from breaking (I'm not > mentioning any names) but this can get out of control and does more > harm than good.
The only cases, IMHO, that should require a fix in a stable kernel release is a bug that affects system stability. Any other type of bug should be fixed in the development tree and wait until the next stable release. This includes performace and security problems.
I have absolutely no problems with breaking binary modules/drivers/etc. across stable releases or even WITHIN a development release. However, WITHIN a stable release, there should be NOTHING more important than maintaining stability. Maintaining or improving stability should take precedence over everything else, INCLUDING performance and security (and I'm a security person!).
> On another issue, the fact that things which stick their noses into > kernel memory like lsof even exist, is a bad thing in itself. If the > facilities completely necessary for such a tool do not exist in procfs > as it exists now, the new features necessary should be added so that > there are no common programs which need to look at the kernels > internal data structures via kmem at all.
It's not just LSOF that fails. _ANY_ binary kernel module will fail. AFS fails. The binary serial or ethernet drivers fail too. It's not just the kmem interface that breaks; insmod breaks as well! And _THAT_ is what I'm complaining about. And every other person who has to maintain a binary kernel module is complaining too. Unfortunately there aren't enough of us to make our voices heard.
As an example, there was one 2.0.x patch which changed the ordering of entries in some kernel structure "for caching reasons". I'm sorry, but this is a completely gratuitous change that should wait for a development release. This is trading off stability vs. some (unclear) performance gain, and should have waited for 2.1.x.
If I sound upset about this; that's because I am. I maintain a binary-only distribution of the Andrew File System (AFS) for Linux. I cannot release source code because it is copyrighted by Transarc Corp. Luckily they allow me to distribute binaries of the port. However, everytime the kernel symbols change, I need to make YET ANOTHER distribution. I shouldn't need to do this in what is supposed to be a stable release. If things are changing this drastically, then clearly it is not stable and should not be labeled as such.
-derek
PS: I love Linux, but if the 2.2 release cannot remain stabvle like the 1.2 release, I'm seriously going to have to give up Linux for another OS which does remain stable. Luckily NetBSD is easily available to me.
-- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord@MIT.EDU PGP key available
|  |