linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* RE: obsolete code must die
@ 2001-06-14 10:22 Heusden, Folkert van
  2001-06-14 13:05 ` Nils Holland
  0 siblings, 1 reply; 59+ messages in thread
From: Heusden, Folkert van @ 2001-06-14 10:22 UTC (permalink / raw)
  To: Daniel, Linux kernel

Yeah, and while you're at it: make it closed source and ask big time $$
for every single line of update.
If your stupid idea will be followed, a lot of african people will not
be happy. (me neither. proud owner of a 486 (at home))

-----Original Message-----
From: Daniel [mailto:ddickman@nyc.rr.com]
Sent: donderdag 14 juni 2001 2:44
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/

^ permalink raw reply	[flat|nested] 59+ messages in thread
* Re: obsolete code must die
@ 2001-06-14 14:01 Jesse Pollard
  2001-06-14 17:21 ` richard
  0 siblings, 1 reply; 59+ messages in thread
From: Jesse Pollard @ 2001-06-14 14:01 UTC (permalink / raw)
  To: jaswinder.singh, Daniel, Linux kernel; +Cc: Jaswinder Singh

---------  Received message begins Here  ---------

> 
> Cleanup is a nice idea , but Linux should support old hardware and should
> not affect them in any way.
> 
> Jaswinder.

I agree - and added my comments below.

> ----- Original Message -----
> From: "Daniel" <ddickman@nyc.rr.com>
> To: "Linux kernel" <linux-kernel@vger.kernel.org>
> Sent: Wednesday, June 13, 2001 5:44 PM
> 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.

I'm still using 486 systems.... Works fine for a DSL firewall. Why change it?
I'd have to buy a whole new system. The case won't hold anything newer - so
it costs $600-$800; I'd rather put that into fixing up the house... or getting
a newer workstation (1.4 GHz looks REALLY nice). I don't need high performance
for a firewall that only handles ~700Kbits/sec over a 10 base T network.

I also understand that 386 systems make excellent terminal servers...

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

Not when the code must support register save/restore on context switches.
Now the meat of the emulator perhaps. But then you must also provide a
way for applications that don't know about the lack to suddenly have access
to a new library, accessed via a kernel trap (illegal instruction). This
imposes more context switches on an already slow system (though why anywone
would use floating point on one is beyond me ... maybe performance tracking
of firewall/terminal server use...).

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

Not on the 386/486 systems (at least the ISA/EISA based ones).

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

really? I'm still running my printer this way (and just bought a parallel
printer/copier/scanner - the USB port isn't finished yet). And one of my
serial mice. Not to mention the plan to add the UPS to the serial lines....
It's still cheaper to use existing serial ports than to buy 4 serial ports
for USB. USB doesn't buy me any performance advantage (yet).

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


-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

^ permalink raw reply	[flat|nested] 59+ messages in thread

end of thread, other threads:[~2001-06-15 19:46 UTC | newest]

Thread overview: 59+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <Pine.LNX.4.21.0106140018140.14934-100000@imladris.rielhome .conectiva>
2001-06-14  0:44 ` obsolete code must die 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
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

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