linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: obsolete code must die
@ 2001-06-14 14:01 Jesse Pollard
  2001-06-14 17:21 ` richard
  0 siblings, 1 reply; 50+ 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] 50+ messages in thread

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

Ok here are my only 2cents, I use some of this hardware that this clean up
would kill, I dont like that thought, and my brand spanking new 1.2ghz
athalon has a single ISA slot and on board parallel / serial ports all of
which are in use so maybee those should be kept, I however I do agree that a
smaller kernal would be nice, could some of these older hardware devices be
kept out of the kernal? I dont have a clue, I agree on most aspects of why
this cleanup should take place, but to what extent? is it an option to take
some of this out of the kernal and still support it? maybee in userspace?
dont have a clue. but lets not kill everything in this list.


thanks for listening and any feedback
Richard Reynolds
Richard.Reynolds@usa.net
----- Original Message -----
From: "Jesse Pollard" <pollard@tomcat.admin.navo.hpc.mil>
To: <jaswinder.singh@3disystems.com>; "Daniel" <ddickman@nyc.rr.com>; "Linux
kernel" <linux-kernel@vger.kernel.org>
Cc: "Jaswinder Singh" <jaswinder.singh@3disystems.com>
Sent: Thursday, June 14, 2001 7:01 AM
Subject: Re: obsolete code must die


> ---------  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.
> -
> 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] 50+ messages in thread

* Re: obsolete code must die
  2001-06-13 22:23     ` Rafael Diniz
@ 2001-06-15 19:45       ` Eric Hancock
  0 siblings, 0 replies; 50+ messages in thread
From: Eric Hancock @ 2001-06-15 19:45 UTC (permalink / raw)
  To: Rafael Diniz; +Cc: linux-kernel

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?


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

* Re: obsolete code must die
  2001-06-15  3:48   ` Michael Peddemors
@ 2001-06-15 14:21     ` Horst von Brand
  0 siblings, 0 replies; 50+ messages in thread
From: Horst von Brand @ 2001-06-15 14:21 UTC (permalink / raw)
  To: Michael Peddemors; +Cc: Claudio Martins, linux-kernel

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

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

* Re: obsolete code must die
  2001-06-14  7:56           ` Alan Cox
                               ` (3 preceding siblings ...)
  2001-06-15  3:58             ` Michael Peddemors
@ 2001-06-15 11:51             ` Rogier Wolff
  4 siblings, 0 replies; 50+ messages in thread
From: Rogier Wolff @ 2001-06-15 11:51 UTC (permalink / raw)
  To: Alan Cox; +Cc: Rainer Mager, linux-kernel

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. 

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

* Re: obsolete code must die
  2001-06-15  3:58             ` Michael Peddemors
@ 2001-06-15  4:09               ` Joel Jaeggli
  0 siblings, 0 replies; 50+ messages in thread
From: Joel Jaeggli @ 2001-06-15  4:09 UTC (permalink / raw)
  To: Michael Peddemors; +Cc: Alan Cox, linux-kernel

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.



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

* Re: obsolete code must die
  2001-06-14  7:56           ` Alan Cox
                               ` (2 preceding siblings ...)
  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
  4 siblings, 1 reply; 50+ messages in thread
From: Michael Peddemors @ 2001-06-15  3:58 UTC (permalink / raw)
  To: Alan Cox; +Cc: linux-kernel

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


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

* Re: obsolete code must die
  2001-06-14  0:44 ` Daniel
                     ` (20 preceding siblings ...)
  2001-06-14 18:57   ` Mike A. Harris
@ 2001-06-15  3:48   ` Michael Peddemors
  2001-06-15 14:21     ` Horst von Brand
  21 siblings, 1 reply; 50+ messages in thread
From: Michael Peddemors @ 2001-06-15  3:48 UTC (permalink / raw)
  To: Claudio Martins; +Cc: linux-kernel

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


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

* Re: obsolete code must die
  2001-06-14  1:08   ` Colonel
  2001-06-13 22:23     ` Rafael Diniz
@ 2001-06-14 19:00     ` Mike A. Harris
  1 sibling, 0 replies; 50+ messages in thread
From: Mike A. Harris @ 2001-06-14 19:00 UTC (permalink / raw)
  To: Colonel; +Cc: linux-kernel

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!


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

* Re: obsolete code must die
  2001-06-14  0:44 ` Daniel
                     ` (19 preceding siblings ...)
  2001-06-14 15:15   ` Brad Johnson
@ 2001-06-14 18:57   ` Mike A. Harris
  2001-06-15  3:48   ` Michael Peddemors
  21 siblings, 0 replies; 50+ messages in thread
From: Mike A. Harris @ 2001-06-14 18:57 UTC (permalink / raw)
  To: Daniel; +Cc: Linux kernel

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.


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

* Re: obsolete code must die
  2001-06-14  0:44 ` Daniel
                     ` (18 preceding siblings ...)
  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
  21 siblings, 0 replies; 50+ messages in thread
From: Brad Johnson @ 2001-06-14 15:15 UTC (permalink / raw)
  To: Daniel; +Cc: Linux kernel

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. 

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

* Re: obsolete code must die
  2001-06-14  7:56           ` 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 11:51             ` Rogier Wolff
  4 siblings, 0 replies; 50+ messages in thread
From: Michael Bacarella @ 2001-06-14 14:45 UTC (permalink / raw)
  To: linux-kernel

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

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

* Re: obsolete code must die
  2001-06-14 10:22 Heusden, Folkert van
@ 2001-06-14 13:05 ` Nils Holland
  0 siblings, 0 replies; 50+ messages in thread
From: Nils Holland @ 2001-06-14 13:05 UTC (permalink / raw)
  To: Linux kernel

On Thursday 14 June 2001 12:22, Heusden, Folkert van wrote:
> 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))

Well, although I am not involved in developement of the kernel, I'm pretty 
much about this "cleaning up" idea. While I'm not one of those folks who are 
actually working on the code, I don't see a reason for limiting the range of 
hardware that Linux suppurts, which is what this clean-up would do.

Some ideas that have been presented here are not of much relevance to me, but 
I think dropping support for the serial and parallel ports is an insane idea. 
Why not also stop supporting other devices that are in use by probably 70% of 
the users?

Besides the fact that Linux is free, stable and fast, I have always liked the 
fact that I could put it on almost any machine I got my hands on. That holds 
true to my fastest Athlon with 512 MB of RAM, as well as for a 486SX with 16 
MB of RAM.  With Linux, even such old machines could be put to good use. And 
now, after this suggested clean-up, I wouldn't even be able to use my non-USB 
supporting Pentium machines anymore. I wonder what that would be good for.

I really cannot imagine that the older features in the kernel are big 
problems of any kind that make it impossible (or harder) for the developers 
to focus on supporting new features. The only thing a clean-up would do is 
probably making a whole lot of users unhappy.

Greetings
Nils

-- 
----------------------------------------------------------
Nils Holland - nils@nightcastleproductions.org
NightCastle Productions - Linux in Tiddische, Germany
http://www.nightcastleproductions.org
"They asked me where this earthquake would begin,
 I offered to let them feel my pulse."
----------------------------------------------------------

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

* Re: obsolete code must die
  2001-06-14  2:22   ` Alan Olsen
                       ` (2 preceding siblings ...)
  2001-06-14  8:35     ` Bohdan Vlasyuk
@ 2001-06-14 10:25     ` Andrzej Krzysztofowicz
  3 siblings, 0 replies; 50+ messages in thread
From: Andrzej Krzysztofowicz @ 2001-06-14 10:25 UTC (permalink / raw)
  To: Alan Olsen; +Cc: Daniel, Linux kernel

> 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

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

* RE: obsolete code must die
@ 2001-06-14 10:22 Heusden, Folkert van
  2001-06-14 13:05 ` Nils Holland
  0 siblings, 1 reply; 50+ 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] 50+ messages in thread

* Re: obsolete code must die
  2001-06-14  0:44 ` Daniel
                     ` (17 preceding siblings ...)
  2001-06-14  8:44   ` Luigi Genoni
@ 2001-06-14  9:55   ` Thomas Pornin
  2001-06-14 15:15   ` Brad Johnson
                     ` (2 subsequent siblings)
  21 siblings, 0 replies; 50+ messages in thread
From: Thomas Pornin @ 2001-06-14  9:55 UTC (permalink / raw)
  To: linux-kernel

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

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

* Re: obsolete code must die
  2001-06-14  7:56           ` Alan Cox
  2001-06-14  9:06             ` Ghozlane Toumi
@ 2001-06-14  9:24             ` James Sutherland
  2001-06-14 14:45             ` Michael Bacarella
                               ` (2 subsequent siblings)
  4 siblings, 0 replies; 50+ messages in thread
From: James Sutherland @ 2001-06-14  9:24 UTC (permalink / raw)
  To: Alan Cox; +Cc: Rainer Mager, linux-kernel

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.


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

* Re: obsolete code must die
  2001-06-14  7:56           ` Alan Cox
@ 2001-06-14  9:06             ` Ghozlane Toumi
  2001-06-14  9:24             ` James Sutherland
                               ` (3 subsequent siblings)
  4 siblings, 0 replies; 50+ messages in thread
From: Ghozlane Toumi @ 2001-06-14  9:06 UTC (permalink / raw)
  To: Alan Cox, Rainer Mager; +Cc: linux-kernel

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


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

* Re: obsolete code must die
  2001-06-14  0:44 ` Daniel
                     ` (16 preceding siblings ...)
  2001-06-14  7:12   ` L. K.
@ 2001-06-14  8:44   ` Luigi Genoni
  2001-06-14  9:55   ` Thomas Pornin
                     ` (3 subsequent siblings)
  21 siblings, 0 replies; 50+ messages in thread
From: Luigi Genoni @ 2001-06-14  8:44 UTC (permalink / raw)
  To: Daniel; +Cc: Linux kernel



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



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

* Re: obsolete code must die
  2001-06-14  2:22   ` Alan Olsen
  2001-06-14  1:24     ` Robert Love
  2001-06-14  1:41     ` David Luyer
@ 2001-06-14  8:35     ` Bohdan Vlasyuk
  2001-06-14 10:25     ` Andrzej Krzysztofowicz
  3 siblings, 0 replies; 50+ messages in thread
From: Bohdan Vlasyuk @ 2001-06-14  8:35 UTC (permalink / raw)
  To: Linux kernel

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






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

* Re: obsolete code must die
  2001-06-14  1:45         ` Rainer Mager
@ 2001-06-14  7:56           ` Alan Cox
  2001-06-14  9:06             ` Ghozlane Toumi
                               ` (4 more replies)
  0 siblings, 5 replies; 50+ messages in thread
From: Alan Cox @ 2001-06-14  7:56 UTC (permalink / raw)
  To: Rainer Mager; +Cc: linux-kernel

> 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


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

* Re: obsolete code must die
  2001-06-14  0:44 ` Daniel
                     ` (15 preceding siblings ...)
  2001-06-14  6:31   ` Russell King
@ 2001-06-14  7:12   ` L. K.
  2001-06-14  8:44   ` Luigi Genoni
                     ` (4 subsequent siblings)
  21 siblings, 0 replies; 50+ messages in thread
From: L. K. @ 2001-06-14  7:12 UTC (permalink / raw)
  To: Daniel; +Cc: Linux kernel

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


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

* Re: obsolete code must die
  2001-06-14  6:31   ` Russell King
@ 2001-06-14  6:54     ` Daniel Dickman
  0 siblings, 0 replies; 50+ messages in thread
From: Daniel Dickman @ 2001-06-14  6:54 UTC (permalink / raw)
  To: Linux kernel

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



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

* Re: obsolete code must die
  2001-06-14  0:44 ` Daniel
                     ` (14 preceding siblings ...)
  2001-06-14  3:48   ` Stephen Satchell
@ 2001-06-14  6:31   ` Russell King
  2001-06-14  6:54     ` Daniel Dickman
  2001-06-14  7:12   ` L. K.
                     ` (5 subsequent siblings)
  21 siblings, 1 reply; 50+ messages in thread
From: Russell King @ 2001-06-14  6:31 UTC (permalink / raw)
  To: Daniel; +Cc: Linux kernel

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


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

* Re: obsolete code must die
  2001-06-14  3:48   ` Stephen Satchell
@ 2001-06-14  4:26     ` Rik van Riel
  0 siblings, 0 replies; 50+ messages in thread
From: Rik van Riel @ 2001-06-14  4:26 UTC (permalink / raw)
  To: Stephen Satchell; +Cc: Daniel, Linux kernel

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)


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

* Re: obsolete code must die
  2001-06-14  0:44 ` Daniel
                     ` (13 preceding siblings ...)
  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
                     ` (6 subsequent siblings)
  21 siblings, 1 reply; 50+ messages in thread
From: Stephen Satchell @ 2001-06-14  3:48 UTC (permalink / raw)
  To: Rik van Riel, Daniel; +Cc: Linux kernel

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


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

* Re: obsolete code must die
  2001-06-14  1:55   ` Horst von Brand
@ 2001-06-14  3:41     ` Arnaldo Carvalho de Melo
  0 siblings, 0 replies; 50+ messages in thread
From: Arnaldo Carvalho de Melo @ 2001-06-14  3:41 UTC (permalink / raw)
  To: Horst von Brand; +Cc: Daniel, Linux kernel

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

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

* Re: obsolete code must die
  2001-06-14  0:44 ` Daniel
                     ` (12 preceding siblings ...)
  2001-06-14  2:31   ` James Stevenson
@ 2001-06-14  3:24   ` Rik van Riel
  2001-06-14  3:48   ` Stephen Satchell
                     ` (7 subsequent siblings)
  21 siblings, 0 replies; 50+ messages in thread
From: Rik van Riel @ 2001-06-14  3:24 UTC (permalink / raw)
  To: Daniel; +Cc: Linux kernel

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)


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

* Re: obsolete code must die
  2001-06-14  1:41     ` David Luyer
@ 2001-06-14  2:37       ` Tom Vier
  0 siblings, 0 replies; 50+ messages in thread
From: Tom Vier @ 2001-06-14  2:37 UTC (permalink / raw)
  To: linux-kernel

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

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

* Re: obsolete code must die
  2001-06-14  0:44 ` Daniel
                     ` (11 preceding siblings ...)
  2001-06-14  2:22   ` Alan Olsen
@ 2001-06-14  2:31   ` James Stevenson
  2001-06-14  3:24   ` Rik van Riel
                     ` (8 subsequent siblings)
  21 siblings, 0 replies; 50+ messages in thread
From: James Stevenson @ 2001-06-14  2:31 UTC (permalink / raw)
  To: ddickman; +Cc: linux-kernel


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

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

* Re: obsolete code must die
  2001-06-14  0:44 ` Daniel
                     ` (10 preceding siblings ...)
  2001-06-14  1:58   ` D. Stimits
@ 2001-06-14  2:22   ` Alan Olsen
  2001-06-14  1:24     ` Robert Love
                       ` (3 more replies)
  2001-06-14  2:31   ` James Stevenson
                     ` (9 subsequent siblings)
  21 siblings, 4 replies; 50+ messages in thread
From: Alan Olsen @ 2001-06-14  2:22 UTC (permalink / raw)
  To: Daniel; +Cc: Linux kernel

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


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

* Re: obsolete code must die
  2001-06-14  0:44 ` Daniel
                     ` (9 preceding siblings ...)
  2001-06-14  1:55   ` Horst von Brand
@ 2001-06-14  1:58   ` D. Stimits
  2001-06-14  2:22   ` Alan Olsen
                     ` (10 subsequent siblings)
  21 siblings, 0 replies; 50+ messages in thread
From: D. Stimits @ 2001-06-14  1:58 UTC (permalink / raw)
  To: Daniel; +Cc: Linux kernel

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/

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

* Re: obsolete code must die
  2001-06-14  0:44 ` Daniel
                     ` (8 preceding siblings ...)
  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
                     ` (11 subsequent siblings)
  21 siblings, 1 reply; 50+ messages in thread
From: Horst von Brand @ 2001-06-14  1:55 UTC (permalink / raw)
  To: Daniel; +Cc: Linux kernel

"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

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

* Re: obsolete code must die
  2001-06-14  0:44 ` Daniel
                     ` (7 preceding siblings ...)
  2001-06-14  1:23   ` Justin Guyett
@ 2001-06-14  1:51   ` Mohammad A. Haque
  2001-06-14  1:55   ` Horst von Brand
                     ` (12 subsequent siblings)
  21 siblings, 0 replies; 50+ messages in thread
From: Mohammad A. Haque @ 2001-06-14  1:51 UTC (permalink / raw)
  To: Daniel; +Cc: Linux kernel

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


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

* RE: obsolete code must die
  2001-06-14  1:32       ` Colonel
@ 2001-06-14  1:45         ` Rainer Mager
  2001-06-14  7:56           ` Alan Cox
  0 siblings, 1 reply; 50+ messages in thread
From: Rainer Mager @ 2001-06-14  1:45 UTC (permalink / raw)
  To: linux-kernel

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.


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

* Re: obsolete code must die
  2001-06-14  2:22   ` Alan Olsen
  2001-06-14  1:24     ` Robert Love
@ 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
  3 siblings, 1 reply; 50+ messages in thread
From: David Luyer @ 2001-06-14  1:41 UTC (permalink / raw)
  To: Daniel, Linux kernel



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



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

* Re: obsolete code must die
  2001-06-14  1:24     ` Robert Love
@ 2001-06-14  1:32       ` Colonel
  2001-06-14  1:45         ` Rainer Mager
  0 siblings, 1 reply; 50+ messages in thread
From: Colonel @ 2001-06-14  1:32 UTC (permalink / raw)
  To: linux-kernel

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.

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

* Re: obsolete code must die
  2001-06-14  2:22   ` Alan Olsen
@ 2001-06-14  1:24     ` Robert Love
  2001-06-14  1:32       ` Colonel
  2001-06-14  1:41     ` David Luyer
                       ` (2 subsequent siblings)
  3 siblings, 1 reply; 50+ messages in thread
From: Robert Love @ 2001-06-14  1:24 UTC (permalink / raw)
  To: Alan Olsen; +Cc: Daniel, Linux kernel

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


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

* Re: obsolete code must die
  2001-06-14  0:44 ` Daniel
                     ` (6 preceding siblings ...)
  2001-06-14  1:13   ` Claudio Martins
@ 2001-06-14  1:23   ` Justin Guyett
  2001-06-14  1:51   ` Mohammad A. Haque
                     ` (13 subsequent siblings)
  21 siblings, 0 replies; 50+ messages in thread
From: Justin Guyett @ 2001-06-14  1:23 UTC (permalink / raw)
  To: Daniel; +Cc: Linux kernel

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


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

* Re: obsolete code must die
  2001-06-14  1:05     ` Daniel Dickman
  2001-06-14  1:09       ` Rik van Riel
@ 2001-06-14  1:20       ` Gary E. Miller
  1 sibling, 0 replies; 50+ messages in thread
From: Gary E. Miller @ 2001-06-14  1:20 UTC (permalink / raw)
  To: Daniel Dickman; +Cc: Linux kernel

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



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

* Re: obsolete code must die
  2001-06-14  0:44 ` Daniel
                     ` (5 preceding siblings ...)
  2001-06-14  1:11   ` John Chris Wren
@ 2001-06-14  1:13   ` Claudio Martins
  2001-06-14  1:23   ` Justin Guyett
                     ` (14 subsequent siblings)
  21 siblings, 0 replies; 50+ messages in thread
From: Claudio Martins @ 2001-06-14  1:13 UTC (permalink / raw)
  To: Daniel, Linux kernel

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

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

* RE: obsolete code must die
  2001-06-14  0:44 ` Daniel
                     ` (4 preceding siblings ...)
  2001-06-14  1:08   ` Colonel
@ 2001-06-14  1:11   ` John Chris Wren
  2001-06-14  1:13   ` Claudio Martins
                     ` (15 subsequent siblings)
  21 siblings, 0 replies; 50+ messages in thread
From: John Chris Wren @ 2001-06-14  1:11 UTC (permalink / raw)
  To: Daniel, Linux kernel

	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/


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

* Re: obsolete code must die
  2001-06-14  1:05     ` Daniel Dickman
@ 2001-06-14  1:09       ` Rik van Riel
  2001-06-14  1:20       ` Gary E. Miller
  1 sibling, 0 replies; 50+ messages in thread
From: Rik van Riel @ 2001-06-14  1:09 UTC (permalink / raw)
  To: Daniel Dickman; +Cc: Andrew Pimlott, Linux kernel

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/


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

* Re: obsolete code must die
  2001-06-14  0:44 ` Daniel
                     ` (3 preceding siblings ...)
       [not found]   ` <20010613204729.A18297@pimlott.ne.mediaone.net>
@ 2001-06-14  1:08   ` Colonel
  2001-06-13 22:23     ` Rafael Diniz
  2001-06-14 19:00     ` Mike A. Harris
  2001-06-14  1:11   ` John Chris Wren
                     ` (16 subsequent siblings)
  21 siblings, 2 replies; 50+ messages in thread
From: Colonel @ 2001-06-14  1:08 UTC (permalink / raw)
  To: linux-kernel

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>

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

* Re: obsolete code must die
       [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
  0 siblings, 2 replies; 50+ messages in thread
From: Daniel Dickman @ 2001-06-14  1:05 UTC (permalink / raw)
  To: Andrew Pimlott; +Cc: Linux kernel

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


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

* Re: obsolete code must die
  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>
                     ` (18 subsequent siblings)
  21 siblings, 0 replies; 50+ messages in thread
From: Jeff Garzik @ 2001-06-14  1:00 UTC (permalink / raw)
  To: Daniel; +Cc: Linux kernel

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     |

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

* Re: obsolete code must die
  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
                     ` (19 subsequent siblings)
  21 siblings, 0 replies; 50+ messages in thread
From: Jaswinder Singh @ 2001-06-14  0:56 UTC (permalink / raw)
  To: Daniel, Linux kernel; +Cc: 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/
>


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

* Re: obsolete code must die
  2001-06-14  0:44 ` Daniel
@ 2001-06-14  0:54   ` Rik van Riel
  2001-06-14  0:56   ` Jaswinder Singh
                     ` (20 subsequent siblings)
  21 siblings, 0 replies; 50+ messages in thread
From: Rik van Riel @ 2001-06-14  0:54 UTC (permalink / raw)
  To: Daniel; +Cc: Linux kernel

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/


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

* obsolete code must die
@ 2001-06-14  0:44 ` Daniel
  2001-06-14  0:54   ` Rik van Riel
                     ` (21 more replies)
  0 siblings, 22 replies; 50+ messages in thread
From: Daniel @ 2001-06-14  0:44 UTC (permalink / raw)
  To: Linux kernel

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


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

* Re: obsolete code must die
  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
  1 sibling, 1 reply; 50+ messages in thread
From: Rafael Diniz @ 2001-06-13 22:23 UTC (permalink / raw)
  To: linux-kernel

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

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

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

Thread overview: 50+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-06-14 14:01 obsolete code must die Jesse Pollard
2001-06-14 17:21 ` richard
  -- strict thread matches above, loose matches on Subject: below --
2001-06-14 10:22 Heusden, Folkert van
2001-06-14 13:05 ` Nils Holland
     [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
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  7:56           ` 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

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