obsolete code must die

obsolete code must die

[Daniel]

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

Re: obsolete code must die

[Rik van Riel]

On Wed, 13 Jun 2001, Daniel wrote:

> So without further ado here're the features I want to get rid of:
>
> i386, i486
> math-emu
> ISA bus, MCA bus, EISA bus
> ISA, MCA, EISA device drivers
> parallel/serial/game ports

+--------------------+
|      Please,       |
|    don't feed      |
|       the          |
|     trolls.        |
+--------------------+
          ||
          ||
          ||
          \/


Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: obsolete code must die

[Jaswinder Singh]

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

Jaswinder.

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

Re: obsolete code must die

[Jeff Garzik]

Daniel wrote:
> 
> 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.

If you don't want it, don't build it into your kernel.

-- 
Jeff Garzik      | Andre the Giant has a posse.
Building 1024    |
MandrakeSoft     |

Re: obsolete code must die

[Daniel Dickman]

Hi Andrew,

Thanks for your email. I am aware of the "traditions" of the Linux kernel,
and this is really why I wanted to start a discussion going about this.
Basically one of the things I am wondering is how complex the kernel code
can grow to become. All I am proposing is that old features start becoming
deprecated and eventually removed.

What I'd like to know is this -- will support for the i386, say, ever go
away? What if the hardware is no longer in existence/used by anyone? will
support stay in the kernel?

This is the main point I wanted to make, and I guess I should have been
clearer about this.

Daniel
----- Original Message -----
From: "Andrew Pimlott" <andrew@pimlott.ne.mediaone.net>
To: "Daniel" <ddickman@nyc.rr.com>
Sent: Wednesday, June 13, 2001 8:47 PM
Subject: Re: obsolete code must die


> Do you realize how violently your suggestions conflict with the
> goals, practices, and traditions of Linux?  I don't mean any
> offense, but you should really learn more about Linux development
> before making broad suggestions.
>
> Andrew

Re: obsolete code must die

[Rik van Riel]

On Wed, 13 Jun 2001, Daniel Dickman wrote:

> Thanks for your email. I am aware of the "traditions" of the
> Linux kernel, and this is really why I wanted to start a
> discussion going about this.

OK, so you almost certainly ARE a troll:

1) proposing to remove support for hardware many of us use
   every day
2) on purpose going against tradition
3) replying private email back to the list
4) and all this using  Microsoft Outlook ;)


The hints pointing towards "troll, Troll, TROLL" are
overwhelming.

Lets stop the thread here.

thanks,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: obsolete code must die

[Gary E. Miller]

Yo Daniel!

On Wed, 13 Jun 2001, Daniel Dickman wrote:

> What I'd like to know is this -- will support for the i386, say, ever go
> away? What if the hardware is no longer in existence/used by anyone? will
> support stay in the kernel?

There is an aweful lot of embedded Linux using 386 and 486 class devices.
Just look at all those cheap NAT boxes at Frys.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701
	gem@rellim.com  Tel:+1(541)382-8588 Fax: +1(541)382-8676

Re: obsolete code must die

[Colonel]

In list.kernel, you wrote:
>
>Anyone concerned about the current size of the kernel source code? I am, and

No.  Since you are up to date with the latest in everything, I cannot
see why you would be concerned about a few megabytes in your gigabyte
drives.


>i386, i486
>The Pentium processor has been around since 1995. Support for these older

No.  Both of my cheap on-site systems for occasional access are 486s.
Why would I spend money for a system that is hardly ever used?


>ISA bus, MCA bus, EISA bus
>PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP,
>CONFIG_ISAPNP, etc

No.  There are still plenty of unique ISA cards around.


>MFM/RLL/XT/ESDI hard drive support
>Does anyone still *have* an RLL drive that works? At the very least get rid

OK, I haven't seen one of these for nearly 10 years.


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

Send me the funds to replace my laser printers please.


>a.out
>Who needs it anymore. I love ELF.

OK, everything that I had in a.out was converted within a year of
ELF's introduction.


>I really think doing a clean up is worthwhile. Maybe while looking for stuff

You left out all the old non-IDE CDROM drives.
 

<PS. thanks for the testing of my new archive>

Re: obsolete code must die

[Rafael Diniz]

> >i386, i486
> >The Pentium processor has been around since 1995. Support for these older
>
> No.  Both of my cheap on-site systems for occasional access are 486s.
> Why would I spend money for a system that is hardly ever used?
I have 386's that I still use.

> >ISA bus, MCA bus, EISA bus
> >PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP,
> >CONFIG_ISAPNP, etc
>
> No.  There are still plenty of unique ISA cards around.
How about all the isa ne2000 around the world?

> >MFM/RLL/XT/ESDI hard drive support
> >Does anyone still *have* an RLL drive that works? At the very least get
> > rid
>
> OK, I haven't seen one of these for nearly 10 years.
My 386 have one of these.

> >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.
ow, I think that you are in the future :-)

> Send me the funds to replace my laser printers please.
I want it too.

> >a.out
> >Who needs it anymore. I love ELF.
>
> OK, everything that I had in a.out was converted within a year of
> ELF's introduction.
There are some non open source programs that are a.out...

I want to continue to use Linux on my 386!!!!

Thanks
Rafael Diniz
Brazil

Re: obsolete code must die

[Eric Hancock]

Yes!  I still need ISA support for an ne2000 card.

On Wednesday, June 13, 2001, at 06:23 PM, Rafael Diniz wrote:

>> No.  There are still plenty of unique ISA cards around.
> How about all the isa ne2000 around the world?

Re: obsolete code must die

[Mike A. Harris]

On Wed, 13 Jun 2001, Colonel wrote:

>>I really think doing a clean up is worthwhile. Maybe while looking for stuff
>
>You left out all the old non-IDE CDROM drives.

And also UP systems.  I've got 2 SMP boxes here now.  Why not
remove support for any system with less than 2 processors?  ;o)

I'll just have to replace my 486 firewall with the dual 486 in
the closet.  ;o)


----------------------------------------------------------------------
    Mike A. Harris  -  Linux advocate  -  Open Source advocate
       Opinions and viewpoints expressed are solely my own.
----------------------------------------------------------------------
If Bill Gates had a dime for every time Windows crashed, he'd be rich!

RE: obsolete code must die

[John Chris Wren]

	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/

Re: obsolete code must die

[Claudio Martins]

On Thursday 14 June 2001 01:44, Daniel wrote:

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

  You mean you want 2.5+ series to just stop supporting all older hardware?

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

  Allow me to disagree. There are still plenty of those machines around. 
Imagine how many of these are offering some kind of service somewhere on 
Internet... A 100MHz 486 is still a good machine, if your task is computing 
related and not "desktop" related (since most actual desktop systems are not 
happy with less than 64MB RAM and other features no commonly present on 486 
machines ;). I have 486 at home and I intend to continue using it.

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

  Right now I'm listening to my mp3 music in my ESS ISA sound card. If I like 
to listen to music while I work and I have a sound card that works why the 
heck do I need to buy a new PCI one?

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

   Not so fast with these ones. And serial and parallel ports are sometimes 
very useful, especially if you deal with electronics and/or are involved in 
prototipe electronics and similar (although I'm trying to move to the much 
better USB port :)


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


  I surely agree that cleaning up old stuff is very important, but please 
agree that one of the strenghts of Linux is that you don't need so powerfull 
or so advanced hardware to do the jobs, as some commercial alternatives 
require, you can reuse some hardware that would be otherwise obsolete, so YOU 
SAVE SOME BUCKS.
   As a student, Radio Amateur and Electronics entusiast, many times I have 
to rely on old and surplus hardware since money resources are scarce. Linux 
lets me have fun, even with low resources. Thats the key to sucess IMO.

regards

  Claudio

Re: obsolete code must die

[Justin Guyett]

On Wed, 13 Jun 2001, Daniel wrote:

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

hmm... what about processors like cris?  The big brother of the processor
in the cute net-enabled-webcam by axis?  AFAIK it doesn't have an fpu, and
people put a lot of work into getting support for it into 2.4.

> ISA, MCA, EISA device drivers
> If support for the buses is gone, there's no point in supporting devices for
> these buses.

Fine, but can you leave in support for my PAS16?

> all code marked as CONFIG_OBSOLETE
> Since we're cleaning house we may as well get rid of this stuff.

No real problem there...

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

Wow, thanks for leaving me with no way to console into my netra.
Incidentally, (As if anyone appropriate is actually READING this thread),
can people who make distributions PLEASE not assume there are 3 or 4
serial ports?  I tried installing debian-sparc on my netra and init
warnings about being unable to open the 3rd serial port make menus
unreadable.

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

Yeah, can we please get rid of ext2?  I mean, everyone's using reiserfs
now, right?  And what about making SMP mandatory?  I mean, who only has
*ONE* processor in a machine in 2001?  And ide and scsi support... ram is
so cheap now who needs disk?  get rid of everything except ramdisk.  tape
drives?  cd burners?  obsolete.  Plus the RIAA doesn't want cd burners
anyway.  Maybe you can get funding for 2.6 kernel development from them
with this plan!


Justin

Re: obsolete code must die

[Mohammad A. Haque]

On Wed, 13 Jun 2001, Daniel wrote:

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

One of the things that makes linux great is being able to actually put
all that old hardware to use. Heck, I know people who use Mac SE still
(running BSD though .. but still same idea).

Yeah, sure I can run older kernels. But what if I want say .. the new
and improved VM that's available in say 2.6? What then?

-- 

=====================================================================
Mohammad A. Haque                              http://www.haque.net/
                                               mhaque@haque.net

  "Alcohol and calculus don't mix.             Project Lead
   Don't drink and derive." --Unknown          http://wm.themes.org/
                                               batmanppc@themes.org
=====================================================================

Re: obsolete code must die

[Horst von Brand]

"Daniel" <ddickman@nyc.rr.com> said:

[...]

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

How much does this contribute? I guess the _truly_ i[34]86 dependent code
is a few hundred lines, if that much. Besides, you would probably be
surprised at the number of those machines in use.

[...]

> ISA bus, MCA bus, EISA bus
> PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP,
> CONFIG_ISAPNP, etc

Just too bad that 2 out of my 4 machines at home are ISA only, this one is
ISA/PCI; and of the servers at work a lowly P/155 (just ISA) is doing
useful work as the connection point for modems.


[...]

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

No non-paralell printers in sight for me. Some 2 dozen printers in all.

[...]

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

Try it, and come back with patches.
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616

Re: obsolete code must die

[Arnaldo Carvalho de Melo]

Em Wed, Jun 13, 2001 at 09:55:54PM -0400, Horst von Brand escreveu:
> "Daniel" <ddickman@nyc.rr.com> said:
> > 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.
> 
> Try it, and come back with patches.

hey, the KJP needs volunteers to tackle this bug/cleanup list:

http://bazar.conectiva.com.br/~acme/TODO

More info available at http://kernel-janitor.sourceforge.net/, the Stanford
Checker also found bugs that have to be fixed (link provided in the KJP
page), please help.

As for what I want to get rid of? Bugs, getting rid of those would be
excellent ;)

- Arnaldo (the one that is porting a network stack to 2.4 that would warrant
           death penalty if Daniel was the judge ;) )

Re: obsolete code must die

[D. Stimits]

Daniel wrote:
> 
> 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.

This is completely wrong. USB is a hog, IEEE 1394 joysticks? Almost
every sound card out there...modern...have game ports that are useful
now. USB is an evolving and often broken standard. Your idea of obsolete
is not completely wrong, but it is far too wrong to go about it this
way. And printers or serial mice?

D. Stimits, stimits@idcomm.com

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

Re: obsolete code must die

[Alan Olsen]

On Wed, 13 Jun 2001, Daniel wrote:

I agree that some clean up is needed.  (The size of the kernel is getting
HUGE. Back in the old days, we didn't have kernels larger than a few
hundred kbytes.  That is because we had to type in the kernel source from
source written on papyrus.)

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

You are in a part of the world that can afford them.

In Third World countries, however, Pentiums are not always the norm. You
are cutting off a good chunk of the world here.

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

How does getting rid of math-emu effect compilation on other platforms?

Not just Intel out there...

> ISA bus, MCA bus, EISA bus
> PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP,
> CONFIG_ISAPNP, etc

This I strongly disagree with.

There are alot of ISA cards still in use.  (I have a USR 56k voice/fax
modem that still works great. How many Sound Blaster 16 cards are still
being used? Lots, i would guess.)

It may not be pretty, but it is still widely used. (Even in the US.)

> ISA, MCA, EISA device drivers
> If support for the buses is gone, there's no point in supporting devices for
> these buses.

I am not certain if tis is a good idea, for the reason given above.  (Not
certain about MCA and EISA though.)  

> all code marked as CONFIG_OBSOLETE
> Since we're cleaning house we may as well get rid of this stuff.

I don't have an argument there, except when it has not been that way long.

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

I am not certain how much this stuff is still used outside the US.  The XT
driver still being around does surprise me though.  (Will that even *work*
on modern hardware?  I didn't think you could get that card to work on a
386.)

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

This is BAD idea.  This sort of joystick was produced until reciently.
They are still in use.  You will piss off a bunch of gamers this way.
(Yanking a gamer's joystick is never a good idea.)

> a.out
> Who needs it anymore. I love ELF.

How much legacy code is still out there? How much will still run on 2.4? I
don't see this one as a problem, but I expect that there are some special
cases that will keep it alive.

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

I would like to see a clean up of the documentation.  (As well as new docs
written.) Getting an updated list of all the parameters that can be passed
to the kernel would be a nice start.  (The current list looks pretty old.)

I do agree that some parts need to be cut off from the main tree.  Maybe
this clean-up should be a part of 2.5? 2.7? 6.6.6?

alan@ctrl-alt-del.com | Note to AOL users: for a quick shortcut to reply
Alan Olsen            | to my mail, just hit the ctrl, alt and del keys.
 "All power is derived from the barrel of a gnu." - Mao Tse Stallman

Re: obsolete code must die

[Robert Love]

On 13 Jun 2001 19:22:38 -0700, Alan Olsen wrote:
> On Wed, 13 Jun 2001, Daniel wrote:
> <snip>
> > ISA bus, MCA bus, EISA bus
> > PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP,
> > CONFIG_ISAPNP, etc
> 
> This I strongly disagree with.
> 
> There are alot of ISA cards still in use.  (I have a USR 56k voice/fax
> modem that still works great. How many Sound Blaster 16 cards are still
> being used? Lots, i would guess.)
> <snip>

i think we are all missing the ball here: i am happy when i see driver
support for a piece of hardware that i have _NEVER_ heard of and at most
_ONE_ person uses it.  why?  it means more stuff works in linux.  we
dont need to defend how many people use hardware X.  if you have X, good
for you.  if not, you dont care, but at least good for linux as a whole.

driver support does not effect me if i dont use said driver.

in an ideal world, my kernel is super-small (ultra-optimized code) but
the full kernel source is huge (lots of platform and driver support).

lets stop fanning the flames and let this (Microsoft-using, as Rik
pointed out) troll die off.

-- 
Robert M. Love
rml@ufl.edu
rml@tech9.net

Re: obsolete code must die

[Colonel]

In list.kernel, you wrote:

>i think we are all missing the ball here: i am happy when i see driver
>support for a piece of hardware that i have _NEVER_ heard of and at most
>_ONE_ person uses it.  why?  it means more stuff works in linux.  we
>dont need to defend how many people use hardware X.  if you have X, good
>for you.  if not, you dont care, but at least good for linux as a whole.

Good Point!

>lets stop fanning the flames and let this (Microsoft-using, as Rik
>pointed out) troll die off.

Agreed, he made the filter already.  But it was good for some laughs,
checking a few cobwebs and I really didn't see flames.  Plus I got to
test my new mailing list archive.

RE: obsolete code must die

[Rainer Mager]

I agree that removing support for any hardware is a bad idea but I question
the idea of putting it all in one monolithic download (tar file). If we're
considering the concern for less developed nations with older hardware,
imagine how you would like to download the whole kernel with an old 2400 bps
modem. Not a fun thought.

Would it make sense to create some sort of 'make config' script that
determines what you want in your kernel and then downloads only those
components? After all, with the constant release of new hardware, isn't a
50MB kernel release not too far away? 100MB?


--Rainer

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Colonel
> Sent: Thursday, June 14, 2001 10:32 AM
> To: linux-kernel@vger.kernel.org
> Subject: Re: obsolete code must die
>
>
> In list.kernel, you wrote:
>
> >i think we are all missing the ball here: i am happy when i see driver
> >support for a piece of hardware that i have _NEVER_ heard of and at most
> >_ONE_ person uses it.  why?  it means more stuff works in linux.  we
> >dont need to defend how many people use hardware X.  if you have X, good
> >for you.  if not, you dont care, but at least good for linux as a whole.
>
> Good Point!
>
> >lets stop fanning the flames and let this (Microsoft-using, as Rik
> >pointed out) troll die off.
>
> Agreed, he made the filter already.  But it was good for some laughs,
> checking a few cobwebs and I really didn't see flames.  Plus I got to
> test my new mailing list archive.

Download process for a "split kernel" (was: obsolete code must die)

[David Luyer]

> I agree that removing support for any hardware is a bad idea but I question
> the idea of putting it all in one monolithic download (tar file). If we're
> considering the concern for less developed nations with older hardware,
> imagine how you would like to download the whole kernel with an old 2400 bps
> modem. Not a fun thought.
> 
> Would it make sense to create some sort of 'make config' script that
> determines what you want in your kernel and then downloads only those
> components? After all, with the constant release of new hardware, isn't a
> 50MB kernel release not too far away? 100MB?

This might actually make sense - a kernel composed of multiple versioned
segments.  A tool which works out dependencies of the options being selected,
downloads the required parts if the latest versions of those parts are not
already downloaded, and then builds the kernel (or could even build during
the download, as soon as the build dependencies for each block of the kernel
are satisfied, if you want to be fancy...).  

Or as a simpler design, something like;

  * a copy of the kernel maintained in a CVS tree
  * kernel download would pull down:
        * the build script
        * a file containing the list of filenames depended on by
          each config option
  * build script builds the config and then cvs updates the file list
    and the files for each config option in question to the version as
    tagged in the build script

Someone could relatively easily maintain this separate to all the kernel 
developers, and it would mean only ever having to download files you were
actually using.

David.
-- 
David Luyer                                        Phone:   +61 3 9674 7525
Engineering Projects Manager   P A C I F I C       Fax:     +61 3 9699 8693
Pacific Internet (Australia)  I N T E R N E T      Mobile:  +61 4 1111 2983
http://www.pacific.net.au/                         NASDAQ:  PCNTF

Re: Download process for a "split kernel" (was: obsolete code must die)

[Jaswinder Singh]

>
> Or as a simpler design, something like;
>
>   * a copy of the kernel maintained in a CVS tree
>   * kernel download would pull down:
>         * the build script
>         * a file containing the list of filenames depended on by
>           each config option
>   * build script builds the config and then cvs updates the file list
>     and the files for each config option in question to the version as
>     tagged in the build script
>
> Someone could relatively easily maintain this separate to all the kernel
> developers, and it would mean only ever having to download files you were
> actually using.

OR

50 % of kernel size is from /linux/drivers
25 % of kernel size is from machine dependent /linux/arch/XXXX and
/linux/include/XXXX

If  we are able to divide Linux tree in such a way that everyone can
download it from from their personnal modems and enjoy linux.

may be i am wrong .

But i love downloading whole kernel and i usually refer different
architectures.

Thank you,

Best Regards,

Jaswinder.
--
These are my opinions not 3Di.

Re: Download process for a "split kernel" (was: obsolete code must die)

[Daniel Phillips]

On Thursday 14 June 2001 04:00, David Luyer wrote:
> > Would it make sense to create some sort of 'make config' script that
> > determines what you want in your kernel and then downloads only those
> > components? After all, with the constant release of new hardware, isn't a
> > 50MB kernel release not too far away? 100MB?
>
> This might actually make sense - a kernel composed of multiple versioned
> segments.  A tool which works out dependencies of the options being
> selected, downloads the required parts if the latest versions of those
> parts are not already downloaded, and then builds the kernel...

This sounds a lot like apt-get, doesn't it?

> ... (or could even
> build during the download, as soon as the build dependencies for each block
> of the kernel are satisfied, if you want to be fancy...).

This is fancier alright:

  1) walk
  2) run

It's the kind of power tool that will be pretty easy to graft onto ESR's new 
cml2 code base.  I'd love to see better apt-get hooks into the kernel 
config/download/build/install.

--
Daniel

Re: Download process for a "split kernel" (was: obsolete code must die)

[Alexander Viro]

On Thu, 14 Jun 2001, Daniel Phillips wrote:

> This sounds a lot like apt-get, doesn't it?

Folks, RTFFAQ, please. URL is attached to the end of each posting.

Re: Download process for a "split kernel" (was: obsolete code must die)

[Daniel Phillips]

On Thursday 14 June 2001 10:34, Alexander Viro wrote:
> On Thu, 14 Jun 2001, Daniel Phillips wrote:
> > This sounds a lot like apt-get, doesn't it?
>
> Folks, RTFFAQ, please. URL is attached to the end of each posting.

The FAQ blesses the idea of people setting up incremental download services, 
condems the idea of asking Linus to change his procedures to support this.  
It has nothing to say about the idea of leveraging the cml2 code base to let 
apt-get configure and build kernels better, which was the point of my post.
  
Presumably you want this question added to the FAQ? ;-)

--
Daniel

Re: Download process for a "split kernel" (was: obsolete code must die)

[Richard Gooch]

Daniel Phillips writes:
> On Thursday 14 June 2001 10:34, Alexander Viro wrote:
> > On Thu, 14 Jun 2001, Daniel Phillips wrote:
> > > This sounds a lot like apt-get, doesn't it?
> >
> > Folks, RTFFAQ, please. URL is attached to the end of each posting.
> 
> The FAQ blesses the idea of people setting up incremental download
> services, condems the idea of asking Linus to change his procedures
> to support this.

As it should.

> It has nothing to say about the idea of leveraging the cml2 code
> base to let apt-get configure and build kernels better, which was
> the point of my post.

That has been left as an excercise for the FAQ reader.

> Presumably you want this question added to the FAQ? ;-)

Going into this in detail is not the purpose of the FAQ, but a small,
concise patch will be looked upon favourably :-) A link to a more
detailed page would nicely supplement a small chunk of text.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: Download process for a "split kernel" (was: obsolete code must die)

[Horst von Brand]

David Luyer <david_luyer@pacific.net.au> said:

[...]

> This might actually make sense - a kernel composed of multiple versioned
> segments.  A tool which works out dependencies of the options being selected,
> downloads the required parts if the latest versions of those parts are not
> already downloaded, and then builds the kernel (or could even build during
> the download, as soon as the build dependencies for each block of the kernel
> are satisfied, if you want to be fancy...).

Please do look at the archives to find out just why this idea is floated
each 3 to 4 months and then shot down, and why.
-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: Download process for a "split kernel" (was: obsolete code must die)

[David Luyer]

  (I wrote)
> > This might actually make sense - a kernel composed of multiple versioned
> > segments.  A tool which works out dependencies of the options being selected,
> > downloads the required parts if the latest versions of those parts are not
> > already downloaded, and then builds the kernel (or could even build during
> > the download, as soon as the build dependencies for each block of the kernel
> > are satisfied, if you want to be fancy...).
> 
> Please do look at the archives to find out just why this idea is floated
> each 3 to 4 months and then shot down, and why.

Well, I'm actually looking at the 2nd idea I mentioned in my e-mail -- a very 
small "kernel package" which has a config script, a list of config options and
the files they depend on and an appropriately tagged CVS tree which can then be
used for a compressed checkout of a version to do a build.  (Or maybe something
more bandwidth-friendly than CVS for the initial checkout.)

Maybe I'll find the spare time to do it, maybe I won't, either way I won't post
any more on the subject until I have something tangible (so far I've just 
done the 'easy bit': written a quick shell script which imported 2.4.x into a
tagged CVS tree; the 'hard bit', to write a script to analyse each kernel rev
and determine which files are used by which config options and mix that in
together with the minimal install for a 'make menuconfig' will take somewhat
longer).

David.
-- 
David Luyer                                        Phone:   +61 3 9674 7525
Engineering Projects Manager   P A C I F I C       Fax:     +61 3 9699 8693
Pacific Internet (Australia)  I N T E R N E T      Mobile:  +61 4 1111 2983
http://www.pacific.net.au/                         NASDAQ:  PCNTF

Re: Download process for a "split kernel" (was: obsolete code must die)

[Rob Landley]

On Thursday 14 June 2001 08:14, David Luyer wrote:

> Well, I'm actually looking at the 2nd idea I mentioned in my e-mail -- a
> very small "kernel package" which has a config script, a list of config
> options and the files they depend on and an appropriately tagged CVS tree
> which can then be used for a compressed checkout of a version to do a
> build.  (Or maybe something more bandwidth-friendly than CVS for the
> initial checkout.)
>
> Maybe I'll find the spare time to do it, maybe I won't, either way I won't
> post any more on the subject until I have something tangible (so far I've
> just done the 'easy bit': written a quick shell script which imported 2.4.x
> into a tagged CVS tree; the 'hard bit', to write a script to analyse each
> kernel rev and determine which files are used by which config options and
> mix that in together with the minimal install for a 'make menuconfig' will
> take somewhat longer).
>
> David.

You might want to float this idea by Eric Raymond.  It's POSSIBLE (distant 
but possible) that the new CML2 stuff might make this sort of thing easier to 
automate.

Correction, it's possible CML2 might make this POSSIBLE to automate.  It 
sounds like it would still be a female dog and a half to implement.  But I'm 
not the one to ask...

Rob

Re: obsolete code must die

[Alan Cox]

> Would it make sense to create some sort of 'make config' script that
> determines what you want in your kernel and then downloads only those
> components? After all, with the constant release of new hardware, isn't a
> 50MB kernel release not too far away? 100MB?

This should be a FAQ entry.

For folks doing kernel development a split tree is a nightmare to manage so
we dont bother. Nothing stops a third party splitting and maintaining the tools
to download just the needed bits for those who want to do it that way

Re: obsolete code must die

[Ghozlane Toumi]

----- Original Message -----
From: "Alan Cox" <alan@lxorguk.ukuu.org.uk>
Subject: Re: obsolete code must die


> > Would it make sense to create some sort of 'make config' script that
> > determines what you want in your kernel and then downloads only those
> > components? After all, with the constant release of new hardware, isn't
a
> > 50MB kernel release not too far away? 100MB?
>
> This should be a FAQ entry.

actually, it *is* a FAQ entry ...
http://www.tux.org/lkml/#s7-7

ghoz

Re: obsolete code must die

[James Sutherland]

On Thu, 14 Jun 2001, Alan Cox wrote:

> > Would it make sense to create some sort of 'make config' script that
> > determines what you want in your kernel and then downloads only those
> > components? After all, with the constant release of new hardware, isn't a
> > 50MB kernel release not too far away? 100MB?
>
> This should be a FAQ entry.
>
> For folks doing kernel development a split tree is a nightmare to
> manage so we dont bother. Nothing stops a third party splitting and
> maintaining the tools to download just the needed bits for those who
> want to do it that way

I vaguely remember a distro shipping a kernel source tree without the
non-i386 arch directories. Looked like a good idea at first - saved a fair
chunk of disk space, and didn't break anything. Then you try applying a
patch, and get a truckload of errors... Easier just to keep the whole
thing together, IMO.


James.

Re: obsolete code must die

[Michael Bacarella]

> > Would it make sense to create some sort of 'make config' script that
> > determines what you want in your kernel and then downloads only those
> > components? After all, with the constant release of new hardware, isn't a
> > 50MB kernel release not too far away? 100MB?
> 
> This should be a FAQ entry.
> 
> For folks doing kernel development a split tree is a nightmare to manage so
> we dont bother. Nothing stops a third party splitting and maintaining the tools
> to download just the needed bits for those who want to do it that way

At the risk of crashing my server, I've written something like this for
my hippy friends who don't have hard drive space.

http://datamorphism.com/linux.cgi

It's very elementary, targetted at extremely savvy people (who are
probably above web interface, go figure :), but it basically allows
one to build a custom kernel archive sans unwanted cpu archs/drivers.

The way it does this is very trivial (exclude directories from
arch or drivers while tarring), but some people have nice results.
The only snags are that the build depends on some driver directories existing
even if you're not using the code in them.

What should probably happen is I wait for CML2, write a web interface to it,
and then build an archive based on whatever users configure.

Anyone want to help out on this? I have some kind of archive caching so
there's only a finite number of possible archives that can be generated,
but my biggest fear is that my machine isn't man enough to handle the
load.

-- 
Michael Bacarella <mbac@nyct.net>
Technical Staff / System Development,
New York Connect.Net, Ltd.

Re: obsolete code must die

[Michael Peddemors]

Oh come on Alan, I heard that you still get time to sleep at least 4-5
hours a night.. I am sure you can fit it in..

> This should be a FAQ entry.
> 
> For folks doing kernel development a split tree is a nightmare to manage so
> we dont bother. Nothing stops a third party splitting and maintaining the tools
> to download just the needed bits for those who want to do it that way
> 

-- 
"Catch the Magic of Linux..."
--------------------------------------------------------
Michael Peddemors - Senior Consultant
LinuxAdministration - Internet Services
NetworkServices - Programming - Security
WizardInternet Services http://www.wizard.ca
Linux Support Specialist - http://www.linuxmagic.com
--------------------------------------------------------
(604)589-0037 Beautiful British Columbia, Canada

Re: obsolete code must die

[Joel Jaeggli]

It's got to be hard to maintain the hack till four sleep till noon
lifestyle when you have jury duty...

;)

On 14 Jun 2001, Michael Peddemors wrote:

> Oh come on Alan, I heard that you still get time to sleep at least 4-5
> hours a night.. I am sure you can fit it in..
>
> > This should be a FAQ entry.
> >
> > For folks doing kernel development a split tree is a nightmare to manage so
> > we dont bother. Nothing stops a third party splitting and maintaining the tools
> > to download just the needed bits for those who want to do it that way
> >
>
>

-- 
--------------------------------------------------------------------------
Joel Jaeggli				       joelja@darkwing.uoregon.edu
Academic User Services			     consult@gladstone.uoregon.edu
     PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E
--------------------------------------------------------------------------
It is clear that the arm of criticism cannot replace the criticism of
arms.  Karl Marx -- Introduction to the critique of Hegel's Philosophy of
the right, 1843.

Re: obsolete code must die

[Rogier Wolff]

Alan Cox wrote:
> > Would it make sense to create some sort of 'make config' script that
> > determines what you want in your kernel and then downloads only those
> > components? After all, with the constant release of new hardware, isn't a
> > 50MB kernel release not too far away? 100MB?
> 
> This should be a FAQ entry.

It is. 7.7 .

			Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 

Re: obsolete code must die

[David Luyer]

Obsolete code must die.  Hardware support must live on.

> > ISA, MCA, EISA device drivers
> > If support for the buses is gone, there's no point in supporting devices for
> > these buses.
> 
> I am not certain if tis is a good idea, for the reason given above.  (Not
> certain about MCA and EISA though.)  

MCA is common for PS/2's, which are still around.

> > 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)
> 
> I am not certain how much this stuff is still used outside the US.  The XT
> driver still being around does surprise me though.  (Will that even *work*
> on modern hardware?  I didn't think you could get that card to work on a
> 386.)

Could never get my OMTI 8627 ESDI controller to work under Linux when I tried.
It works under DOS/Win, Xenix and VSTa though.  These controllers were
pseudo-common early 386 machines (before the 386sx and 386dx) built for
Xenix.

Surprisingly the old NEC ESDI drive still spins up, when most of the 1998 or
1999 Seagates/IBM drives are dead or dying and we've had close to an entire
A1000 Sun disk unit fail to spin up -- the 'top-end' disks of today rarely
seem to last more than 2-3 years (in that if you turn them off after 2-3
years of continual service and turn them back on 1/2 hr later, half of the
drives which haven't spat out a drive head in the interim years will fail
to spin up).

Even old Eagle drives from 1988 still spin up... given you have to flick the
starter switch to spin them up half a dozen times, but they still work...
seems they don't make disk drives like they used to.

David.
-- 
David Luyer                                        Phone:   +61 3 9674 7525
Engineering Projects Manager   P A C I F I C       Fax:     +61 3 9699 8693
Pacific Internet (Australia)  I N T E R N E T      Mobile:  +61 4 1111 2983
http://www.pacific.net.au/                         NASDAQ:  PCNTF

Re: obsolete code must die

[Tom Vier]

i have a corvus 20meg drive and a xebec 10meg that both still spin up. those
are from mid to late 80s. i have seagate hawks from '94 that still work, but
quantums from the same period are all dead. the difference is that newer
drives have much tighter tolerances and are much more sensitive to dust. it
varies from drive to drive, of course.

On Thu, Jun 14, 2001 at 11:41:15AM +1000, David Luyer wrote:
> Even old Eagle drives from 1988 still spin up... given you have to flick the
> starter switch to spin them up half a dozen times, but they still work...
> seems they don't make disk drives like they used to.

-- 
Tom Vier <tmv5@home.com>
DSA Key id 0x27371A2C

Re: obsolete code must die

[Bohdan Vlasyuk]

On Wed, Jun 13, 2001 at 07:22:38PM -0700, Alan Olsen wrote:

> > 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.
> You are in a part of the world that can afford them.
> 
> In Third World countries, however, Pentiums are not always the norm. You
> are cutting off a good chunk of the world here.
I agree. There're REALLY much i386s around there. There're more ISA
that PCI network cards here. And I'm really sad that a friend of mine
can't install Linux on his 286, and he should use that bloated
Dos/Windoze 3.1

Re: obsolete code must die

[Andrzej Krzysztofowicz]

> On Wed, 13 Jun 2001, Daniel wrote:
> > MFM/RLL/XT/ESDI hard drive support
> > Does anyone still *have* an RLL drive that works? At the very least get rid

RLL ? Curently no. But I have a dosen of working ST225 with a dosen of ST11M
MFM controllers. Some of them ar\e still in use, mainly for booting purposes
(LILO) ... 

> > of the old driver (eg CONFIG_BLK_DEV_HD_ONLY, CONFIG_BLK_DEV_HD_IDE,
> > CONFIG_BLK_DEV_XD, CONFIG_BLK_DEV_PS2)
> 
> I am not certain how much this stuff is still used outside the US.  The XT
> driver still being around does surprise me though.  (Will that even *work*
> on modern hardware?  I didn't think you could get that card to work on a
> 386.)

Most of the boards work fine with 486. However, in most cases the BIOS
low-level-format routine does not work on them (timing issues). So low level
formatting needs a 386.
I think all of them should work on 586+ if without BIOS...

Andrzej

Re: obsolete code must die

[James Stevenson]

Hi

>-- a simpler, cleaner kernel will also be of more use in an academic
>environment.

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

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

i use all of the above and also require some of the new feature though you 
say good for academic in the UK most of the places are still running 486's 
as workstations when they come to though them out soon you wanna at least 
let the run a linux course with them first :)

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

these are possible in greater usage than you think. isdn cards still look 
like serial ports etc... scanner and where do you plug a joy stick in i 
have never even seen a usb joystick. hey i dont even have USB ports.

though i do agree that there is alot of stuff there but its still mostly 
drivers.

-- 
---------------------------------------------
Web: http://www.stev.org
Mobile: +44 07779080838
E-Mail: mistral@stev.org
  2:20am  up 14:45,  6 users,  load average: 0.10, 0.18, 0.42

Re: obsolete code must die

[Rik van Riel]

On Wed, 13 Jun 2001, Daniel wrote:

OK, after my earlier troll posting, lets go over Daniel's
reasons point by point. Well actually, all of these points
fit in one argument.

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

Everything you propose to get rid of are DRIVERS.  They
do NOT complicate the core kernel, do NOT introduce bugs
in the core kernel and have absolutely NOTHING to do with
how simple or maintainable the core kernel is.

All of the arguments you give above are irrelevant to the
things you propose to have removed from the kernel.

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

They have that option NOW, but in the future people may no
longer be interested in doing essential things like security
updates or network protocol updates to older kernels.

Also, forcing people to use these older kernels will only ADD
to the maintenance problems of the Linux kernel, instead of
making them less ... since then we'd have to release security
and network protocol updates against more kernel versions.

It would also make it impossible for people to combine new and
old hardware in one machine. Think of ham radio operators or
physics people who have their own home-brewn hardware for packet
radio or data acquisition.

It's not your arguments or the things you propose that make me
think you're a troll. It's the fact that the things you propose
are completely unrelated to the arguments you give for them ;)

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: obsolete code must die

[Stephen Satchell]

At 12:24 AM 6/14/01 -0300, Rik van Riel wrote:
>Everything you propose to get rid of are DRIVERS.  They
>do NOT complicate the core kernel, do NOT introduce bugs
>in the core kernel and have absolutely NOTHING to do with
>how simple or maintainable the core kernel is.

Not quite.  There were two non-driver suggestions that the man did 
make:  remove 386/486 support and remove floating-point emulation 
support.  Both are bad for the embedded-systems space, because the 486 is 
still used there widely.

Are all the bus support code exclusively in drivers, or is there something 
compiled into the nucleus for start-up?

I didn't see your "don't feed the troll" sign before...

Satch

Re: obsolete code must die

[Rik van Riel]

On Wed, 13 Jun 2001, Stephen Satchell wrote:
> At 12:24 AM 6/14/01 -0300, Rik van Riel wrote:
> >Everything you propose to get rid of are DRIVERS.  They
> >do NOT complicate the core kernel, do NOT introduce bugs
> >in the core kernel and have absolutely NOTHING to do with
> >how simple or maintainable the core kernel is.
> 
> Not quite.  There were two non-driver suggestions that the man did
> make:  remove 386/486 support and remove floating-point emulation
> support.  Both are bad for the embedded-systems space, because the 486
> is still used there widely.

Both are waaaay outside the core of the kernel, though.

> Are all the bus support code exclusively in drivers, or is there
> something compiled into the nucleus for start-up?

They're compiled into the nucleus (if you want to), but
they're in no way clogging up the source code of the core
kernel.

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: obsolete code must die

[Russell King]

On Wed, Jun 13, 2001 at 08:44:11PM -0400, Daniel wrote:
> 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.

Is this one big joke?  It looks like it to me.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: obsolete code must die

[Daniel Dickman]

Okay, I didn't realize how much opposition there would be to this, 
thanks for all the input. If you'd like to add anything to this, please 
email me personally -- the mailing list has probably seen enough traffic 
regarding this issue. :-)

Thanks
Daniel

Re: obsolete code must die

[L. K.]

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

a lot of people use linux on old machine in networking environmens as
routers/firewalls.


> 
> 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 network cards are still used. Even the new motherboard producers add
an ISA slot on their MB.


> 
> ISA, MCA, EISA device drivers
> If support for the buses is gone, there's no point in supporting devices for
> these buses.

Sometimes a ISA card performs better than a PCI one.




/me

Re: obsolete code must die

[Luigi Genoni]

On Wed, 13 Jun 2001, Daniel wrote:

> 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.
Please, I have a lot of 486 that I use for many secondary things and a
386, why I should not be able to run the latest kernel on them?
In princip, linux have to support all old hardware out there.
>
> 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?
see previuos
>
> ISA, MCA, EISA device drivers
> If support for the buses is gone, there's no point in supporting devices for
> these buses.
Again, a lot of modern MB comes out with at less one isa slot, and anyway
isa bus is present also without the slot on all MB since it has to be
there. how many users are happy
with their old sound blaster 16 on ISA, or with their old
isa modem and would never change it? they should never be forced.
>
> 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)
see previous
>
> 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.
see previous
>
> a.out
> Who needs it anymore. I love ELF.
and how many are happy to play doom with a.out svgalibs??
>
my 2 cents
Luigi

Re: obsolete code must die

[Thomas Pornin]

In article <01a401c0f46b$20b932e0$480e6c42@almlba4sy7xn6x> you write:
> -- Getting rid of old code can help simplify the kernel. This means less
> chance of bugs.

Actually, what you suggest is simply getting rid of users. It would
sure simplify things greatly.

Are you nihilist ?


	--Thomas Pornin

Re: obsolete code must die

[Brad Johnson]

On Wed, Jun 13, 2001 at 08:44:11PM -0400, Daniel wrote:
> 
> 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.

FYI:  Dell still ships computers with on-board sound via ISA bus.

-- 
Words of wisdom from Dr. J.
==============================================================================
Klein bottle for rent -- inquire within. 

Re: obsolete code must die

[Mike A. Harris]

On Wed, 13 Jun 2001, Daniel wrote:

>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.
[SNIP]

Boy, if this isn't a troll, I don't know what is.  Obviously
someone doesn't grok the kernel development processes very well.
Newbie here?

One needn't even *be* a kernel hacker to understand why all of
the stuff stated is totally not going to happen, and there would
be no benefit to doing so.


----------------------------------------------------------------------
    Mike A. Harris  -  Linux advocate  -  Open Source advocate
       Opinions and viewpoints expressed are solely my own.
----------------------------------------------------------------------
Foot and mouth disease is believed by experts to be the first virus
that is unable to spread via Microsoft Outlook.

Re: obsolete code must die

[Michael Peddemors]

This seems to be drifting into that old argument(s) of a forked kernel..
And of course here I am adding to the flotsams..and threadsomes

2.5 for Pentium Plus generation.

<2.4 For older hardware..

Ducking the inevitable flames, I think for the most part, there might be
justification for some forking.. (read obsolesence)

Anyone with a <486 probably shudders at the space and time requirements
of compiling modern kernels.. All they need is the older kernels.. 
The older boxes don't support the new hardware anyways..
But then there is always someone who will find a way to marry a new PCI
or USB bus to an older CPU, and it is nice that 'one kernel to bind
them' philosophy of linux..

But in this age of 'disposability' more and more people just accept they
have to buy new hardware every 3-5 years.. For those that want to
maintain Linux on that, so be it..

Maybe we need more Alan Cox's, and then we could have sperate kernel
trees, Linus's which is the mmmmmother.. (HI MOM!) and the pre-pentium
tree, the post-pentium tree, the embedded tree etc..

But in reality, with all the people contributing now to one tree, there
is still more work to be done.. Who wants to split those resources?

But it is a legitimate argument...

In reality, hardware needs drive kernel upgrades.. and of course some
security issues.. Those who have older hardware aren't interested in
upgrading the kernel, why should they.. it is rock solid as it is..
And newer machines don't need support for the older hardware..

If you want to stay bleading edge kernel wise, usually you stay bleeding
edge hardware wise.. But it is nice the we now can apply the power of
iptables to older 486 firewalls..

BUT as much as it might be cleaner, and a little less headaches to drop
all the fluff that doesn't usually get used, is it worth dropping it
when all newer hardware doesn't care about a little bloat.. *cough* I
can't believe I just supported bloat..  Okay, me personally, I wouldn't
mind seeing tiny litle kernels and tiny little code trees, makes me feel
more effecient, and I don't get blurry eyes from grepping so much code..

(Personally sometimes I think all this new power is wasted in PC's is
wasted, but I have to admit.. these 10 second compiles vs the old 28
hour ones are nice)

On 14 Jun 2001 02:13:29 +0100, Claudio Martins wrote:
> On Thursday 14 June 2001 01:44, Daniel wrote:
> 
> > -- 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.
> >
> 
>   You mean you want 2.5+ series to just stop supporting all older hardware?
-- 
"Catch the Magic of Linux..."
--------------------------------------------------------
Michael Peddemors - Senior Consultant
LinuxAdministration - Internet Services
NetworkServices - Programming - Security
WizardInternet Services http://www.wizard.ca
Linux Support Specialist - http://www.linuxmagic.com
--------------------------------------------------------
(604)589-0037 Beautiful British Columbia, Canada

Re: obsolete code must die

[Horst von Brand]

Claudio Martins <ctpm@vega.net.dhis.org> said:

[...]

> Anyone with a <486 probably shudders at the space and time requirements
> of compiling modern kernels..
... which they do on their newer machine anyway, as the i386 in the closet
is a router that sports no compiler.

> The older boxes don't support the new hardware anyways..
... so support for old hardware has to stay (unless it hurts somewhere,
which is rather uncommon)

[...]

> But in this age of 'disposability' more and more people just accept they
> have to buy new hardware every 3-5 years.. For those that want to
> maintain Linux on that, so be it..

There are places in the world where a i486sx is viewed with awe... and i386
are commonplace. Don't fall into the trap of "All Linux PCs are in the US".
Besides, if the piece of junk does its job well, why buy an expensive,
completely overqualified new machine for it? Sure would make PC makers
happy, but I'm not _that_ interested in their happiness to tell the truth.

> Maybe we need more Alan Cox's, and then we could have sperate kernel
> trees, Linus's which is the mmmmmother.. (HI MOM!) and the pre-pentium
> tree, the post-pentium tree, the embedded tree etc..

... and a nightmare where nobody knows the state of <favorite driver> in
<targeted kernel tree> and has to cross-port all kind of stuff to get
<random machine> to work.

> But in reality, with all the people contributing now to one tree, there
> is still more work to be done.. Who wants to split those resources?

Bingo!
-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513