Messages in this thread | | | Date | Thu, 10 Aug 2000 15:02:56 -0400 | From | Brian Gerst <> | Subject | Re: Complaint about recent LINUX_VERSION_CODEs |
| |
Theodore Ts'o wrote: > > Date: Thu, 10 Aug 2000 10:58:04 -0400 > From: Brian Gerst <bgerst@didntduck.org> > > The only logical reason to not use KERNEL_VERSION is if you want to > support 2.0.x (which should be deprecated, IMHO anyways). > > There *are* still people using 2.0 in production environments. Without > naming names, let's just say that some important parts of the > Internet/web infrastructure are still using Linux 2.0 systems, and that > if you've surfed the web lately, you've probably used a 2.0 system > without knowing it. > > As Alan Cox has pointed out 2.0 probably had the most stable VM, > compared to either 2.2 or 2.4..... For folks who don't need the sexy > new features of the newer kernels, sometimes staying on the older > kernels for stability's sake makes good operational sense.
On the other hand, is it really necessary to carry 2.0's baggage on forever in the current kernel in the form of #ifdef's sprinkled throughout the source code (some of which are not trivial)? For a good example of what I'm trying to say, try to make sense of the Advansys driver... There's cruft dating back to 1.2 in there (including alternate PCI configuration functions), and it's a rat's nest of ifdefs. That's the most extreme case, but there are other places in the kernel that could use some cleanup as well. The line needs to be drawn somewhere or else these thing are going to continue to collect.
I also would like to point out that many of the drivers in 2.4 with 2.0 conditional code, wouldn't compile on 2.0 anyways, because of changes that are unmarked. The driver maintainers need to go through and evaluate what versions they want to support, and clean up their drivers accordingly.
--
Brian Gerst
- 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/
| |