linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "John Chris Wren" <jcwren@jcwren.com>
To: "Daniel" <ddickman@nyc.rr.com>,
	"Linux kernel" <linux-kernel@vger.kernel.org>
Subject: RE: obsolete code must die
Date: Wed, 13 Jun 2001 21:11:12 -0400	[thread overview]
Message-ID: <NDBBKBJHGFJMEMHPOPEGEEJHCJAA.jcwren@jcwren.com> (raw)
In-Reply-To: <01a401c0f46b$20b932e0$480e6c42@almlba4sy7xn6x>

	As an end user who uses cheap laptops for firewalls, I'm pretty much
against this.  I've got 2.2.18, 2.4.4-ac8, and 2.4.4-ac12 installed as
firewall machines on 486 laptops.  Why should we (the collective Linux
world, not me personnally, since I'm not a kernel developer) limit the class
of machines people can run?

	In fact, this seems to be one of the appealing features of Linux, that it
runs on any x86 hardware class with a MMU.  It allows people to get involved
in Linux without making a committment to buying a new PC until they know
they like it, or buying a new HD to do a dual boot install to experiment.
Laptops are a particular issue here, because many of the laptops people can
obtain inexpensively ARE 386/486 class machines.

	I'm all for cleaning up the kernel code, but I think it would be better
served by documentation, not by limiting the hardware that can be run.

	I can't speak authoritively on how much of the kernel code is processor
specific, since GCC takes care of most of that.  I do know there are
sections that are affected by the processor selection, but I can't believe
that it's a significantly large enough portion to justify ripping it out in
the name of cleaning it up.

	I do agree with deleting obsolete code, but not obsoleting hardware so we
CAN delete code.

	--John

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Daniel
> Sent: Wednesday, June 13, 2001 20:44 PM
> To: Linux kernel
> Subject: obsolete code must die
>
>
> Anyone concerned about the current size of the kernel source
> code? I am, and
> I propose to start cleaning house on the x86 platform. I mean
> it's all very
> well and good to keep adding features, but stuff needs to go if kernel
> development is to move forward. Before listing the gunk I want to get rid
> of, here's my justification for doing so:
> -- Getting rid of old code can help simplify the kernel. This means less
> chance of bugs.
> -- Simplifying the kernel means that it will be easier for newbies to
> understand and perhaps contribute.
> -- a simpler, cleaner kernel will also be of more use in an academic
> environment.
> -- a smaller kernel is easier to maintain and is easier to re-architect
> should the need arise.
> -- If someone really needs support for this junk, they will
> always have the
> option of using the 2.0.x, 2.2.x or 2.4.x series.
>
> So without further ado here're the features I want to get rid of:
>
> i386, i486
> The Pentium processor has been around since 1995. Support for these older
> processors should go so we can focus on optimizations for the pentium and
> better processors.
>
> math-emu
> If support for i386 and i486 is going away, then so should math emulation.
> Every intel processor since the 486DX has an FPU unit built in. In fact
> shouldn't FPU support be a userspace responsibility anyway?
>
> ISA bus, MCA bus, EISA bus
> PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP,
> CONFIG_ISAPNP, etc
>
> ISA, MCA, EISA device drivers
> If support for the buses is gone, there's no point in supporting
> devices for
> these buses.
>
> all code marked as CONFIG_OBSOLETE
> Since we're cleaning house we may as well get rid of this stuff.
>
> MFM/RLL/XT/ESDI hard drive support
> Does anyone still *have* an RLL drive that works? At the very
> least get rid
> of the old driver (eg CONFIG_BLK_DEV_HD_ONLY, CONFIG_BLK_DEV_HD_IDE,
> CONFIG_BLK_DEV_XD, CONFIG_BLK_DEV_PS2)
>
> parallel/serial/game ports
> More controversial to remove this, since they are *still* in pretty wide
> use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts.
>
> a.out
> Who needs it anymore. I love ELF.
>
> I really think doing a clean up is worthwhile. Maybe while
> looking for stuff
> to clean up we'll even be able to better comment the existing code. Any
> other features people would like to get rid of? Any comments or
> suggestions?
> I'd love to start a good discussion about this going so please
> send me your
> 2 cents.
>
> Daniel
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


  parent reply	other threads:[~2001-06-14  1:11 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.21.0106140018140.14934-100000@imladris.rielhome .conectiva>
2001-06-14  0:44 ` Daniel
2001-06-14  0:54   ` Rik van Riel
2001-06-14  0:56   ` Jaswinder Singh
2001-06-14  1:00   ` Jeff Garzik
     [not found]   ` <20010613204729.A18297@pimlott.ne.mediaone.net>
2001-06-14  1:05     ` Daniel Dickman
2001-06-14  1:09       ` Rik van Riel
2001-06-14  1:20       ` Gary E. Miller
2001-06-14  1:08   ` Colonel
2001-06-13 22:23     ` Rafael Diniz
2001-06-15 19:45       ` Eric Hancock
2001-06-14 19:00     ` Mike A. Harris
2001-06-14  1:11   ` John Chris Wren [this message]
2001-06-14  1:13   ` Claudio Martins
2001-06-14  1:23   ` Justin Guyett
2001-06-14  1:51   ` Mohammad A. Haque
2001-06-14  1:55   ` Horst von Brand
2001-06-14  3:41     ` Arnaldo Carvalho de Melo
2001-06-14  1:58   ` D. Stimits
2001-06-14  2:22   ` Alan Olsen
2001-06-14  1:24     ` Robert Love
2001-06-14  1:32       ` Colonel
2001-06-14  1:45         ` Rainer Mager
2001-06-14  2:00           ` Download process for a "split kernel" (was: obsolete code must die) David Luyer
2001-06-14  2:30             ` Jaswinder Singh
2001-06-14  7:56             ` Daniel Phillips
2001-06-14  8:34               ` Alexander Viro
2001-06-14 16:25                 ` Daniel Phillips
2001-06-14 17:21                 ` Richard Gooch
2001-06-14 12:07             ` Horst von Brand
2001-06-14 12:14               ` David Luyer
2001-06-14 12:18                 ` Rob Landley
2001-06-14  7:56           ` obsolete code must die Alan Cox
2001-06-14  9:06             ` Ghozlane Toumi
2001-06-14  9:24             ` James Sutherland
2001-06-14 14:45             ` Michael Bacarella
2001-06-15  3:58             ` Michael Peddemors
2001-06-15  4:09               ` Joel Jaeggli
2001-06-15 11:51             ` Rogier Wolff
2001-06-14  1:41     ` David Luyer
2001-06-14  2:37       ` Tom Vier
2001-06-14  8:35     ` Bohdan Vlasyuk
2001-06-14 10:25     ` Andrzej Krzysztofowicz
2001-06-14  2:31   ` James Stevenson
2001-06-14  3:24   ` Rik van Riel
2001-06-14  3:48   ` Stephen Satchell
2001-06-14  4:26     ` Rik van Riel
2001-06-14  6:31   ` Russell King
2001-06-14  6:54     ` Daniel Dickman
2001-06-14  7:12   ` L. K.
2001-06-14  8:44   ` Luigi Genoni
2001-06-14  9:55   ` Thomas Pornin
2001-06-14 15:15   ` Brad Johnson
2001-06-14 18:57   ` Mike A. Harris
2001-06-15  3:48   ` Michael Peddemors
2001-06-15 14:21     ` Horst von Brand
2001-06-14 10:22 Heusden, Folkert van
2001-06-14 13:05 ` Nils Holland
2001-06-14 14:01 Jesse Pollard
2001-06-14 17:21 ` richard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=NDBBKBJHGFJMEMHPOPEGEEJHCJAA.jcwren@jcwren.com \
    --to=jcwren@jcwren.com \
    --cc=ddickman@nyc.rr.com \
    --cc=linux-kernel@vger.kernel.org \
    --subject='RE: obsolete code must die' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).