obsolete code must die
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines · you
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!
Quoted 2 lines
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.
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
Quoted 24 lines
-----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 dieQuoted 5 lines · you
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!
Quoted 2 lines
lets stop fanning the flames and let this (Microsoft-using, as Rik pointed out) troll die off.
Agreed, he made the filter already. But it was good for some laughs, checking a few cobwebs and I really didn't see flames. Plus I got to test my new mailing list archive.
Download process for a "split kernel" (was: obsolete code must die)
Quoted 8 lines
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.
Quoted 4 lines
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.
Signature · 4 lines
David Luyer Phone: +61 3 9674 7525 Engineering Projects Manager P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 1111 2983 http://www.pacific.net.au/ NASDAQ: PCNTF
Re: Download process for a "split kernel" (was: obsolete code must die)
David Luyer <[email protected]> said:
[...]
Quoted 6 lines
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.
Signature · 4 lines
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, Chile Fax: +56 32 797513
Re: Download process for a "split kernel" (was: obsolete code must die)
(I wrote)
Quoted 9 lines
Quoted 6 lines
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.
Signature · 4 lines
David Luyer Phone: +61 3 9674 7525 Engineering Projects Manager P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 1111 2983 http://www.pacific.net.au/ NASDAQ: PCNTF
Re: Download process for a "split kernel" (was: obsolete code must die)
In reply to Horst von BrandQuoted 15 lines · David Luyer
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).
Quoted 1 line
David.
You might want to float this idea by Eric Raymond. It's POSSIBLE (distant but possible) that the new CML2 stuff might make this sort of thing easier to automate.
Correction, it's possible CML2 might make this POSSIBLE to automate. It sounds like it would still be a female dog and a half to implement. But I'm not the one to ask...
Rob
Re: Download process for a "split kernel" (was: obsolete code must die)
In reply to Rainer MagerQuoted 12 lines
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
Quoted 3 lines
Someone could relatively easily maintain this separate to all the kernel developers, and it would mean only ever having to download files you were actually using.
OR
50 % of kernel size is from /linux/drivers
25 % of kernel size is from machine dependent /linux/arch/XXXX and /linux/include/XXXX
If we are able to divide Linux tree in such a way that everyone can download it from from their personnal modems and enjoy linux.
may be i am wrong .
But i love downloading whole kernel and i usually refer different architectures.
Thank you,
Best Regards,
Jaswinder.
--
These are my opinions not 3Di.
Re: Download process for a "split kernel" (was: obsolete code must die)
In reply to Rainer MagerQuoted 9 lines · David Luyer
Quoted 4 lines
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?
Quoted 3 lines
... (or could even
build during the download, as soon as the build dependencies for each block of the kernel are satisfied, if you want to be fancy...).
This is fancier alright:
1) walk
2) run
It's the kind of power tool that will be pretty easy to graft onto ESR's new cml2 code base. I'd love to see better apt-get hooks into the kernel config/download/build/install.
--
Daniel
Re: Download process for a "split kernel" (was: obsolete code must die)
Quoted 1 line · Daniel Phillips
This sounds a lot like apt-get, doesn't it?
Folks, RTFFAQ, please. URL is attached to the end of each posting.
Re: Download process for a "split kernel" (was: obsolete code must die)
Quoted 4 lines · Alexander Viro
Quoted 1 line · Daniel Phillips
This sounds a lot like apt-get, doesn't it?
Folks, RTFFAQ, please. URL is attached to the end of each posting.
The FAQ blesses the idea of people setting up incremental download services, condems the idea of asking Linus to change his procedures to support this. It has nothing to say about the idea of leveraging the cml2 code base to let apt-get configure and build kernels better, which was the point of my post.
Presumably you want this question added to the FAQ? ;-)
--
Daniel
Re: Download process for a "split kernel" (was: obsolete code must die)
Quoted 9 lines · Daniel Phillips
Quoted 4 lines · Alexander Viro
Quoted 1 line · Daniel Phillips
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.
Quoted 3 lines
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.
Quoted 1 line
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]
Quoted 4 lines
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
----- Original Message -----
From: "Alan Cox" <[email protected]>
Subject: Re: obsolete code must die
Quoted 3 lines
Quoted 3 lines
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
Quoted 3 lines
Quoted 1 line
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
Quoted 11 lines · Alan Cox
Quoted 4 lines
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.
Oh come on Alan, I heard that you still get time to sleep at least 4-5 hours a night.. I am sure you can fit it in..
Quoted 6 lines
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
Signature · 9 lines
"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
It's got to be hard to maintain the hack till four sleep till noon lifestyle when you have jury duty...
;)
Quoted 11 lines · Michael Peddemors
Oh come on Alan, I heard that you still get time to sleep at least 4-5 hours a night.. I am sure you can fit it in..
Quoted 6 lines
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
Signature · 8 lines
-------------------------------------------------------------------------- Joel Jaeggli [email protected] Academic User Services [email protected] PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -------------------------------------------------------------------------- It is clear that the arm of criticism cannot replace the criticism of arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy of the right, 1843.
Quoted 6 lines · Alan Cox
Quoted 4 lines
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.
Signature · 4 lines
** [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.
Quoted 10 lines
Quoted 4 lines
Would it make sense to create some sort of 'make config' script that determines what you want in your kernel and then downloads only those components? After all, with the constant release of new hardware, isn't a 50MB kernel release not too far away? 100MB?
This should be a FAQ entry.
For folks doing kernel development a split tree is a nightmare to manage so we dont bother. Nothing stops a third party splitting and maintaining the tools to download just the needed bits for those who want to do it that way
At the risk of crashing my server, I've written something like this for my hippy friends who don't have hard drive space.
http://datamorphism.com/linux.cgi
It's very elementary, targetted at extremely savvy people (who are probably above web interface, go figure :), but it basically allows one to build a custom kernel archive sans unwanted cpu archs/drivers.
The way it does this is very trivial (exclude directories from arch or drivers while tarring), but some people have nice results. The only snags are that the build depends on some driver directories existing even if you're not using the code in them.
What should probably happen is I wait for CML2, write a web interface to it, and then build an archive based on whatever users configure.
Anyone want to help out on this? I have some kind of archive caching so there's only a finite number of possible archives that can be generated, but my biggest fear is that my machine isn't man enough to handle the load.
Signature · 3 lines
Michael Bacarella <[email protected]> Technical Staff / System Development, New York Connect.Net, Ltd.