Re: obsolete code must die
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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
Claudio Martins <[EMAIL PROTECTED]> 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 mother.. (HI MOM!) and the pre-pentium > tree, the post-pentium tree, the embedded tree etc.. ... and a nightmare where nobody knows the state of in and has to cross-port all kind of stuff to get 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:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
Alan 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. -- ** [EMAIL PROTECTED] ** 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
Alan 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. -- ** [EMAIL PROTECTED] ** 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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
Claudio Martins [EMAIL PROTECTED] 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 mother.. (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:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 mother.. (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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Download process for a "split kernel" (was: obsolete code must die)
On Thursday 14 June 2001 08:14, David Luyer wrote: > Well, I'm actually looking at the 2nd idea I mentioned in my e-mail -- a > very small "kernel package" which has a config script, a list of config > options and the files they depend on and an appropriately tagged CVS tree > which can then be used for a compressed checkout of a version to do a > build. (Or maybe something more bandwidth-friendly than CVS for the > initial checkout.) > > Maybe I'll find the spare time to do it, maybe I won't, either way I won't > post any more on the subject until I have something tangible (so far I've > just done the 'easy bit': written a quick shell script which imported 2.4.x > into a tagged CVS tree; the 'hard bit', to write a script to analyse each > kernel rev and determine which files are used by which config options and > mix that in together with the minimal install for a 'make menuconfig' will > take somewhat longer). > > David. You might want to float this idea by Eric Raymond. It's POSSIBLE (distant but possible) that the new CML2 stuff might make this sort of thing easier to automate. Correction, it's possible CML2 might make this POSSIBLE to automate. It sounds like it would still be a female dog and a half to implement. But I'm not the one to ask... Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Download process for a "split kernel" (was: obsolete code must die)
Daniel Phillips writes: > On Thursday 14 June 2001 10:34, Alexander Viro wrote: > > On Thu, 14 Jun 2001, Daniel Phillips wrote: > > > This sounds a lot like apt-get, doesn't it? > > > > Folks, RTFFAQ, please. URL is attached to the end of each posting. > > The FAQ blesses the idea of people setting up incremental download > services, condems the idea of asking Linus to change his procedures > to support this. As it should. > It has nothing to say about the idea of leveraging the cml2 code > base to let apt-get configure and build kernels better, which was > the point of my post. That has been left as an excercise for the FAQ reader. > Presumably you want this question added to the FAQ? ;-) Going into this in detail is not the purpose of the FAQ, but a small, concise patch will be looked upon favourably :-) A link to a more detailed page would nicely supplement a small chunk of text. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 [EMAIL PROTECTED] - Original Message - From: "Jesse Pollard" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Daniel" <[EMAIL PROTECTED]>; "Linux kernel" <[EMAIL PROTECTED]> Cc: "Jaswinder Singh" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > > To: "Linux kernel" <[EMAIL PROTECTED]> > > 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 supp
Re: Download process for a "split kernel" (was: obsolete code must die)
On Thursday 14 June 2001 10:34, Alexander Viro wrote: > On Thu, 14 Jun 2001, Daniel Phillips wrote: > > This sounds a lot like apt-get, doesn't it? > > Folks, RTFFAQ, please. URL is attached to the end of each posting. The FAQ blesses the idea of people setting up incremental download services, condems the idea of asking Linus to change his procedures to support this. It has nothing to say about the idea of leveraging the cml2 code base to let apt-get configure and build kernels better, which was the point of my post. Presumably you want this question added to the FAQ? ;-) -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
- 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" <[EMAIL PROTECTED]> > To: "Linux kernel" <[EMAIL PROTECTED]> > 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: [EMAIL PROTECTED] 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 PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 - [EMAIL PROTECTED] 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." -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Download process for a "split kernel" (was: obsolete code must die)
(I wrote) > > This might actually make sense - a kernel composed of multiple versioned > > segments. A tool which works out dependencies of the options being selected, > > downloads the required parts if the latest versions of those parts are not > > already downloaded, and then builds the kernel (or could even build during > > the download, as soon as the build dependencies for each block of the kernel > > are satisfied, if you want to be fancy...). > > Please do look at the archives to find out just why this idea is floated > each 3 to 4 months and then shot down, and why. Well, I'm actually looking at the 2nd idea I mentioned in my e-mail -- a very small "kernel package" which has a config script, a list of config options and the files they depend on and an appropriately tagged CVS tree which can then be used for a compressed checkout of a version to do a build. (Or maybe something more bandwidth-friendly than CVS for the initial checkout.) Maybe I'll find the spare time to do it, maybe I won't, either way I won't post any more on the subject until I have something tangible (so far I've just done the 'easy bit': written a quick shell script which imported 2.4.x into a tagged CVS tree; the 'hard bit', to write a script to analyse each kernel rev and determine which files are used by which config options and mix that in together with the minimal install for a 'make menuconfig' will take somewhat longer). David. -- David LuyerPhone: +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 2983 http://www.pacific.net.au/ NASDAQ: PCNTF - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Download process for a "split kernel" (was: obsolete code must die)
David Luyer <[EMAIL PROTECTED]> said: [...] > This might actually make sense - a kernel composed of multiple versioned > segments. A tool which works out dependencies of the options being selected, > downloads the required parts if the latest versions of those parts are not > already downloaded, and then builds the kernel (or could even build during > the download, as soon as the build dependencies for each block of the kernel > are satisfied, if you want to be fancy...). Please do look at the archives to find out just why this idea is floated each 3 to 4 months and then shot down, and why. -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: obsolete code must die
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:[EMAIL PROTECTED]] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
- Original Message - From: "Alan Cox" <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Download process for a "split kernel" (was: obsolete code must die)
On Thursday 14 June 2001 04:00, David Luyer wrote: > > Would it make sense to create some sort of 'make config' script that > > determines what you want in your kernel and then downloads only those > > components? After all, with the constant release of new hardware, isn't a > > 50MB kernel release not too far away? 100MB? > > This might actually make sense - a kernel composed of multiple versioned > segments. A tool which works out dependencies of the options being > selected, downloads the required parts if the latest versions of those > parts are not already downloaded, and then builds the kernel... This sounds a lot like apt-get, doesn't it? > ... (or could even > build during the download, as soon as the build dependencies for each block > of the kernel are satisfied, if you want to be fancy...). This is fancier alright: 1) walk 2) run It's the kind of power tool that will be pretty easy to graft onto ESR's new cml2 code base. I'd love to see better apt-get hooks into the kernel config/download/build/install. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
> > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Download process for a split kernel (was: obsolete code must die)
On Thursday 14 June 2001 04:00, David Luyer wrote: Would it make sense to create some sort of 'make config' script that determines what you want in your kernel and then downloads only those components? After all, with the constant release of new hardware, isn't a 50MB kernel release not too far away? 100MB? This might actually make sense - a kernel composed of multiple versioned segments. A tool which works out dependencies of the options being selected, downloads the required parts if the latest versions of those parts are not already downloaded, and then builds the kernel... This sounds a lot like apt-get, doesn't it? ... (or could even build during the download, as soon as the build dependencies for each block of the kernel are satisfied, if you want to be fancy...). This is fancier alright: 1) walk 2) run It's the kind of power tool that will be pretty easy to graft onto ESR's new cml2 code base. I'd love to see better apt-get hooks into the kernel config/download/build/install. -- Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: obsolete code must die
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:[EMAIL PROTECTED]] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Download process for a split kernel (was: obsolete code must die)
David Luyer [EMAIL PROTECTED] said: [...] This might actually make sense - a kernel composed of multiple versioned segments. A tool which works out dependencies of the options being selected, downloads the required parts if the latest versions of those parts are not already downloaded, and then builds the kernel (or could even build during the download, as soon as the build dependencies for each block of the kernel are satisfied, if you want to be fancy...). Please do look at the archives to find out just why this idea is floated each 3 to 4 months and then shot down, and why. -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Download process for a split kernel (was: obsolete code must die)
(I wrote) This might actually make sense - a kernel composed of multiple versioned segments. A tool which works out dependencies of the options being selected, downloads the required parts if the latest versions of those parts are not already downloaded, and then builds the kernel (or could even build during the download, as soon as the build dependencies for each block of the kernel are satisfied, if you want to be fancy...). Please do look at the archives to find out just why this idea is floated each 3 to 4 months and then shot down, and why. Well, I'm actually looking at the 2nd idea I mentioned in my e-mail -- a very small kernel package which has a config script, a list of config options and the files they depend on and an appropriately tagged CVS tree which can then be used for a compressed checkout of a version to do a build. (Or maybe something more bandwidth-friendly than CVS for the initial checkout.) Maybe I'll find the spare time to do it, maybe I won't, either way I won't post any more on the subject until I have something tangible (so far I've just done the 'easy bit': written a quick shell script which imported 2.4.x into a tagged CVS tree; the 'hard bit', to write a script to analyse each kernel rev and determine which files are used by which config options and mix that in together with the minimal install for a 'make menuconfig' will take somewhat longer). David. -- David LuyerPhone: +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 2983 http://www.pacific.net.au/ NASDAQ: PCNTF - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 - [EMAIL PROTECTED] 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. -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
- 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 [EMAIL PROTECTED] To: Linux kernel [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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 PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Download process for a split kernel (was: obsolete code must die)
On Thursday 14 June 2001 10:34, Alexander Viro wrote: On Thu, 14 Jun 2001, Daniel Phillips wrote: This sounds a lot like apt-get, doesn't it? Folks, RTFFAQ, please. URL is attached to the end of each posting. The FAQ blesses the idea of people setting up incremental download services, condems the idea of asking Linus to change his procedures to support this. It has nothing to say about the idea of leveraging the cml2 code base to let apt-get configure and build kernels better, which was the point of my post. Presumably you want this question added to the FAQ? ;-) -- Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 [EMAIL PROTECTED] - Original Message - From: Jesse Pollard [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Daniel [EMAIL PROTECTED]; Linux kernel [EMAIL PROTECTED] Cc: Jaswinder Singh [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To: Linux kernel [EMAIL PROTECTED] 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
Re: Download process for a split kernel (was: obsolete code must die)
On Thursday 14 June 2001 08:14, David Luyer wrote: Well, I'm actually looking at the 2nd idea I mentioned in my e-mail -- a very small kernel package which has a config script, a list of config options and the files they depend on and an appropriately tagged CVS tree which can then be used for a compressed checkout of a version to do a build. (Or maybe something more bandwidth-friendly than CVS for the initial checkout.) Maybe I'll find the spare time to do it, maybe I won't, either way I won't post any more on the subject until I have something tangible (so far I've just done the 'easy bit': written a quick shell script which imported 2.4.x into a tagged CVS tree; the 'hard bit', to write a script to analyse each kernel rev and determine which files are used by which config options and mix that in together with the minimal install for a 'make menuconfig' will take somewhat longer). David. You might want to float this idea by Eric Raymond. It's POSSIBLE (distant but possible) that the new CML2 stuff might make this sort of thing easier to automate. Correction, it's possible CML2 might make this POSSIBLE to automate. It sounds like it would still be a female dog and a half to implement. But I'm not the one to ask... Rob - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Download process for a split kernel (was: obsolete code must die)
Daniel Phillips writes: On Thursday 14 June 2001 10:34, Alexander Viro wrote: On Thu, 14 Jun 2001, Daniel Phillips wrote: This sounds a lot like apt-get, doesn't it? Folks, RTFFAQ, please. URL is attached to the end of each posting. The FAQ blesses the idea of people setting up incremental download services, condems the idea of asking Linus to change his procedures to support this. As it should. It has nothing to say about the idea of leveraging the cml2 code base to let apt-get configure and build kernels better, which was the point of my post. That has been left as an excercise for the FAQ reader. Presumably you want this question added to the FAQ? ;-) Going into this in detail is not the purpose of the FAQ, but a small, concise patch will be looked upon favourably :-) A link to a more detailed page would nicely supplement a small chunk of text. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 mother.. (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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
- Original Message - From: Alan Cox [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 wy 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 [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
Em Wed, Jun 13, 2001 at 09:55:54PM -0400, Horst von Brand escreveu: > "Daniel" <[EMAIL PROTECTED]> 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 ;) ) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
"Daniel" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Download process for a "split kernel" (was: obsolete code must die)
> > Or as a simpler design, something like; > > * a copy of the kernel maintained in a CVS tree > * kernel download would pull down: > * the build script > * a file containing the list of filenames depended on by > each config option > * build script builds the config and then cvs updates the file list > and the files for each config option in question to the version as > tagged in the build script > > Someone could relatively easily maintain this separate to all the kernel > developers, and it would mean only ever having to download files you were > actually using. OR 50 % of kernel size is from /linux/drivers 25 % of kernel size is from machine dependent /linux/arch/ and /linux/include/ If we are able to divide Linux tree in such a way that everyone can download it from from their personnal modems and enjoy linux. may be i am wrong . But i love downloading whole kernel and i usually refer different architectures. Thank you, Best Regards, Jaswinder. -- These are my opinions not 3Di. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Download process for a "split kernel" (was: obsolete code must die)
> I agree that removing support for any hardware is a bad idea but I question > the idea of putting it all in one monolithic download (tar file). If we're > considering the concern for less developed nations with older hardware, > imagine how you would like to download the whole kernel with an old 2400 bps > modem. Not a fun thought. > > Would it make sense to create some sort of 'make config' script that > determines what you want in your kernel and then downloads only those > components? After all, with the constant release of new hardware, isn't a > 50MB kernel release not too far away? 100MB? This might actually make sense - a kernel composed of multiple versioned segments. A tool which works out dependencies of the options being selected, downloads the required parts if the latest versions of those parts are not already downloaded, and then builds the kernel (or could even build during the download, as soon as the build dependencies for each block of the kernel are satisfied, if you want to be fancy...). Or as a simpler design, something like; * a copy of the kernel maintained in a CVS tree * kernel download would pull down: * the build script * a file containing the list of filenames depended on by each config option * build script builds the config and then cvs updates the file list and the files for each config option in question to the version as tagged in the build script Someone could relatively easily maintain this separate to all the kernel developers, and it would mean only ever having to download files you were actually using. David. -- David LuyerPhone: +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 2983 http://www.pacific.net.au/ NASDAQ: PCNTF - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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, [EMAIL PROTECTED] > > 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 [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: obsolete code must die
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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Colonel > Sent: Thursday, June 14, 2001 10:32 AM > To: [EMAIL PROTECTED] > 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 LuyerPhone: +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 2983 http://www.pacific.net.au/ NASDAQ: PCNTF - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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: [EMAIL PROTECTED] 2:20am up 14:45, 6 users, load average: 0.10, 0.18, 0.42 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
> >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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
On 13 Jun 2001 19:22:38 -0700, Alan Olsen wrote: > On Wed, 13 Jun 2001, Daniel wrote: > > > 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.) > 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 [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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? [EMAIL PROTECTED] | 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: obsolete code must die
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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]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 [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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" <[EMAIL PROTECTED]> To: "Daniel" <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
Cleanup is a nice idea , but Linux should support old hardware and should not affect them in any way. Jaswinder. - Original Message - From: "Daniel" <[EMAIL PROTECTED]> To: "Linux kernel" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
Cleanup is a nice idea , but Linux should support old hardware and should not affect them in any way. Jaswinder. - Original Message - From: Daniel [EMAIL PROTECTED] To: Linux kernel [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 | - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 [EMAIL PROTECTED] To: Daniel [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: obsolete code must die
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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? [EMAIL PROTECTED] | 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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: [EMAIL PROTECTED] 2:20am up 14:45, 6 users, load average: 0.10, 0.18, 0.42 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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 LuyerPhone: +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 2983 http://www.pacific.net.au/ NASDAQ: PCNTF - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: obsolete code must die
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Colonel Sent: Thursday, June 14, 2001 10:32 AM To: [EMAIL PROTECTED] 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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/ [EMAIL PROTECTED] Alcohol and calculus don't mix. Project Lead Don't drink and derive. --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
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, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Download process for a split kernel (was: obsolete code must die)
I agree that removing support for any hardware is a bad idea but I question the idea of putting it all in one monolithic download (tar file). If we're considering the concern for less developed nations with older hardware, imagine how you would like to download the whole kernel with an old 2400 bps modem. Not a fun thought. Would it make sense to create some sort of 'make config' script that determines what you want in your kernel and then downloads only those components? After all, with the constant release of new hardware, isn't a 50MB kernel release not too far away? 100MB? This might actually make sense - a kernel composed of multiple versioned segments. A tool which works out dependencies of the options being selected, downloads the required parts if the latest versions of those parts are not already downloaded, and then builds the kernel (or could even build during the download, as soon as the build dependencies for each block of the kernel are satisfied, if you want to be fancy...). Or as a simpler design, something like; * a copy of the kernel maintained in a CVS tree * kernel download would pull down: * the build script * a file containing the list of filenames depended on by each config option * build script builds the config and then cvs updates the file list and the files for each config option in question to the version as tagged in the build script Someone could relatively easily maintain this separate to all the kernel developers, and it would mean only ever having to download files you were actually using. David. -- David LuyerPhone: +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 2983 http://www.pacific.net.au/ NASDAQ: PCNTF - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
