From: "richard" <email@example.com> To: "Jesse Pollard" <firstname.lastname@example.org>, <email@example.com>, "Daniel" <firstname.lastname@example.org>, "Linux kernel" <email@example.com> Cc: "Jaswinder Singh" <firstname.lastname@example.org> Subject: Re: obsolete code must die Date: Thu, 14 Jun 2001 10:21:29 -0700 [thread overview] Message-ID: <005501c0f4f6$72f9ce80$4500000a@win2k> (raw) In-Reply-To: <200106141401.JAA39228@tomcat.admin.navo.hpc.mil> 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" <email@example.com> To: <firstname.lastname@example.org>; "Daniel" <email@example.com>; "Linux kernel" <firstname.lastname@example.org> Cc: "Jaswinder Singh" <email@example.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" <firstname.lastname@example.org> > > To: "Linux kernel" <email@example.com> > > 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: firstname.lastname@example.org > > 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 email@example.com > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > >
next prev parent reply other threads:[~2001-06-14 17:22 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2001-06-14 14:01 Jesse Pollard 2001-06-14 17:21 ` richard [this message] -- 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.firstname.lastname@example.org .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
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='005501c0f4f6$72f9ce80$4500000a@win2k' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: obsolete code must die' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).