Messages in this thread | | | Date | Thu, 01 May 2003 20:41:18 -0400 | From | rmoser <> | Subject | Re: Kernel source tree splitting |
| |
*********** REPLY SEPARATOR ***********
On 5/1/2003 at 5:09 PM Randy.Dunlap wrote:
>On Wed, 30 Apr 2003 17:21:02 -0700 "Randy.Dunlap" <rddunlap@osdl.org> >wrote: > >| Hi, >| >| I'm probably misreading this...but, >| >| Have you tried this yet? Does it modify/customize all Kconfig >| and Makefiles for the selected tree splits? >| >| A few days ago, in one tree, I rm-ed arch/{all that I don't need} >| and drivers/{all that I don't need}. >| After that I couldn't run "make *config" because it wants all of >| those files, even if I don't want them. >| >| So there are many edits that needed to be done in lots of >| Kconfig and Makefiles if one selectively pulls or omits certain >| sub-directories. > >and on 2003-04-30 rddunlap wrote: >| I seem to try for simple solutions when possible and feasible. >| >| In this case, if I were doing it, I would try changing (e.g.) in >| arch/i386/kernel/Kconfig, this line: >| source "drivers/eisa/Kconfig" >| to >| optsource "drivers/eisa/Kconfig" >| where optsource means that the file is optional -- if not found, >| ignore it. And then see what happens, how far it can go, >| what the next problem is.... >| >| If this could be made to work, then entire subdirectories/subsystems >| could be optional. > >So I did a proof-of-concept version of this, without modifying any >source code. I rm-ed arch/<many>, drivers/<many>, and fs/<many> >and then wrote a shell script that looks for missing dirs, Kconfigs, >and Makefile.lib files and puts empty ones back in their places. >The shell script only works for what I rm-ed, but it could be made >smarter if anyone wants to pursue this. (attached) >
Yes. Well the build system (kernel configuration) would be modified to instead of having a list of Kconfigs and dir's and Makefile.libs and such, be able to scan a directory of files which tell it about those things. At least, in my design it would.
>After doing that I was able to build and boot that kernel, so it >(concept) did work. >
Well that's good.
>For a kernel source tree that hadn't been built/compiled in, the size >was reduced from roughly 200 MB down to roughly 133 MB. >
............... You know. Maybe it's not enough to split into categories. Maybe it should be categories and categorical breakdowns. I can see 3.0 or something (maybe even 2.8) reaching 1 gig.
--Bluefox Icy >~Randy > >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |