Martin J. Bligh wrote:
>>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.
>
>
> Indeed, I ran across the same thing a while back. Would be *really* nice to
> fix, if only so some poor sod over a modem can download a smaller tarball,
> or save some diskspace.
>
> M.
>
Tried doing this a while ago with my own cvs server. I'd download the
tarball untar it into the cvs dump. I made a modules file tha that
described all kinds of possible modules and then modules that utilized
those and so on until you could just do co -z9 linux-i386 to get a all
the files required to make any i386 linux ...it was mostly to just
separate the archs, not unneeded drivers. Of course i quickly ran into
the make not working without all the other files from the other archs
and i came to the conclusion you couldn't do this without editing
certain build scripts and files (and since I didn't want the files to be
altered in case people would eventually want to call security into
question) i killed the whole idea.
This idea comes and goes like many others. As far as modular
programming goes the kernel isn't written to be very modular, either
that or it is and the build system just looks over that fact. It would
be interesting to see how hard it would be to have the current config to
not only generate its .config but also a list of commands that an
autoconf created ./configure can read and use to generate the makefiles
we then use to build the kernel. it could also help in enforcing
minimum versions instead of hoping the user does it before complaining
to people who could be doing better things with their time. Anyways,
i'm sure this idea has been coined and dropped before as well. So it's
back to the way things are done like normal.
This might also help highlight files that are not really in a natural
place in the tree. If people building for x86 platforms start finding
they need a file that is in the sparc part of the tree then that
suggests that said file is probably at least partly non-arch
specific. This would also apply to, say, the audio and video parts of
the drivers section of the tree.
While these things do get reported on here occasionally, and fixed,
making it possible to wholesale remove parts of the tree that people
naturally assume you *shouldn't* need for a particular config ought to
show these up more easily.
Of course it adds another variable into the mix when people report
build problems....
Peter