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