>
> 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