linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Randy.Dunlap" <rddunlap@osdl.org>
To: mlmoser@comcast.net
Cc: linux-kernel@vger.kernel.org
Subject: Re: Kernel source tree splitting
Date: Thu, 1 May 2003 17:09:58 -0700	[thread overview]
Message-ID: <20030501170958.3f130646.rddunlap@osdl.org> (raw)
In-Reply-To: <20030430172102.69e13ce9.rddunlap@osdl.org>

[-- Attachment #1: Type: text/plain, Size: 4256 bytes --]

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)

After doing that I was able to build and boot that kernel, so it
(concept) did work.

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.

~Randy


| On Wed, 30 Apr 2003 19:46:13 -0400 rmoser <mlmoser@comcast.net> wrote:
| 
| | Eh, Linus won't be happy making a bunch of tarballs.
| | I've made it less work if you read the message here...
| | 
| | The message mirrored at:
| | 
| | http://marc.theaimsgroup.com/?l=linux-kernel&m=105173077417526&w=2
| | 
| | Shows my pre-thought on this subject.  I thought a bit more,
| | and began to come up with a simple sketch to lead the
| | way in case anyone becomes interested.
| | 
| | First off, the kernel tarballs would be built by a script
| | that splits the source tree apart appropriately and tar's it
| | up.  How this is done is explained.
| | 
| | Second off, there's always a script to download that runs
| | wget and gets the source tree from which it was downloaded.
| | The whole thing.  As in, every tarball is downloaded and
| | untar'd for the user, assembling the full kernel source
| | tree (as it would be if you untar'd it now).
| | 
| | Now, I explained LOD's in that message above in small
| | detail.  But, for clarity, LOD's are files which explain
| | which pieces of source in the kernel tree belong to the
| | LOD; what gets added to the config; where their makefiles
| | are; what config options depend on other linux options;
| | and what groups these LOD's are in.
| | 
| | A command such as `make disttree` should read the LOD's,
| | split apart each linux option, tar 'em together, and
| | then compress the tar's.  Then Linus could just scp the
| | new directory of tar's and a script up.
| | 
| | As for download, the script that goes up can be
| | downloaded (duh), and then run (... why do I bother?).
| | Now this script would run in "dumb mode" (unless the
| | user tells it not to maybe?) and rip down the whole
| | tree, untar it, and rebuild the original source tree.
| | I think.  I'm not sure, I really haven't tried yet.
| | I'll tell you how it works after it's implimented, if
| | ever that happens.  This would likely require wget.
| | 
| | Of course there's always the ftp method.  Go download
| | the pieces you want, untar 'em, copy 'em to the same
| | directory, and the build system adjusts.  but newbies
| | and developers, for completely opposite reasons, will
| | want to use the script in dumb mode.
| | 
| | For experienced users, this will make configuration
| | somewhat easier, as the user can avoid being prompted
| | for irrelavent drivers.  This is just a concept idea,
| | not a fully thought-out idea.  What do you think?
| | 
| | --Bluefox Icy

[-- Attachment #2: builder --]
[-- Type: application/octet-stream, Size: 1021 bytes --]

#! /bin/sh
# idea and script by Randy.Dunlap <rddunlap@osdl.org>

# optsource test:  any Kconfig "source <filename>" files that are missing
#	are touched to produce/provide empty files for them;
# make clean ---> make -k clean
#   to ignore missing Makefiles

DIRS="drivers/eisa drivers/mca drivers/mtd drivers/acorn drivers/acorn/scsi drivers/message drivers/message/fusion drivers/message/i2o net/ipx net/decnet drivers/acorn/net drivers/atm drivers/s390 drivers/s390/net net/ax25 net/irda drivers/isdn drivers/telephony net/bluetooth"

LIBDIRS="net/bluetooth net/bluetooth/bnep"
LIBFILES="net/bluetooth/bnep"

# mkdir for each DIRS and touch dir/Kconfig
for dir in $DIRS ; do
	if [ ! -d $dir ]; then
		mkdir $dir
	fi
	if [ ! -f $dir/Kconfig ]; then
		touch $dir/Kconfig
	fi
done

# mkdir for each LIBDIRS
for dir in $LIBDIRS ; do
	if [ ! -d $dir ]; then
		mkdir $dir
	fi
done

# touch Makefile.lib for each LIBFILES
for dir in $LIBDIRS ; do
	if [ ! -f $dir/Makefile.lib ]; then
		touch $dir/Makefile.lib
	fi
done

###

  parent reply	other threads:[~2003-05-02  0:00 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-30 23:46 Kernel source tree splitting rmoser
2003-05-01  0:21 ` Randy.Dunlap
2003-05-01  0:44   ` rmoser
2003-05-01  2:51     ` Randy.Dunlap
2003-05-01 10:13       ` rmoser
2003-05-01  0:52   ` Larry McVoy
2003-05-01  1:00     ` rmoser
2003-05-01 17:28     ` James H. Cloos Jr.
2003-05-01  4:10   ` Martin J. Bligh
2003-05-01  6:14     ` Ed Sweetman
2003-05-01  6:14       ` Peter Riocreux
2003-05-02  0:09   ` Randy.Dunlap [this message]
2003-05-02  0:41     ` rmoser
2003-05-01 11:54 Chuck Ebbert
2003-05-01 14:06 ` Martin J. Bligh
2003-05-01 14:20   ` Willy TARREAU
2003-05-01 14:35     ` Martin J. Bligh
2003-05-01 14:43       ` Willy TARREAU
2003-05-01 15:01       ` Larry McVoy
2003-05-01 15:11         ` Martin J. Bligh
2003-05-01 17:22 ` Balram Adlakha
2003-05-01 17:28   ` Ben Greear
2003-05-01 20:03     ` John Bradford
2003-05-01 16:00 Chuck Ebbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030501170958.3f130646.rddunlap@osdl.org \
    --to=rddunlap@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mlmoser@comcast.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).