Good afternoon,
On Thu, 13 Jan 2000 dg50@daimlerchrysler.com wrote:
> There's quite a bit of pie-in-the-sky here, but I've had an idea that I'd
On the contrary - 1.0 was released last December... :-)
> like to share.
[snip]
> So anything that is designed to streamline what a user must download
> ("user" in this case representing a kernel non-developer) must have
> near-zero impact on the existing development process. It must be invisible
> and transparent.
It is.
> This need not be an all-singing, all dancing tool right from the get-go
> either. In fact, I think a first kick at this cat might have only one user
> option - arch. That alone would reduce download sizes and required storage
> by a factor of however many main arches there are right now - 6? 7?. Later
> versions could be kept general: "I have a SCSI card" "I have a network
> card" "I want sound support" as opposed to "I have an Adaptec Model
> 8000-K1WqA".
Buildkernel 1.0 already does this; it deletes all architectures
(linux/arch/X and linux/include/asm-X) except the one it's currently
running on. To be sure, until I put in a switch to disable this,
Buildkernel is not useful for cross-compiling, but I doubt anyone would
use it for cross-compiling anyways.
Sparc and Sparc64 are intertwined; both trees are kept if building
for either sparc architecture. Additionally, there's a report I'm looking
into about ppc; it appears to require some m68k files.
> However, I worry that the current src tree may not be organized that
> rigidly, that there may be cross-directory dependancies that cannot be
> inferred from a given source code file's position in the filesystem. If
Rather likely, I think. That's what makes this project fun for
you!
If you'd like to pursue this from a userspace perspective (as
your chances of shuffling files around in the source tree for solely this
reason are roughly equivalent to your chances of simultaneously becoming
president and being struck by lightning :-), I'd gladly consider adding
your patches to intelligently remove unneeded code. There are all kinds
of possibilities; a good starting point might be removing support for bus
types that do not work on a given architecture.
Cheers,
- Bill
---------------------------------------------------------------------------
"Scattered showers my ass!"
-- Noah
(Courtesy of "Michael B. Trausch" <mtrausch@wcnet.org>)
--------------------------------------------------------------------------
William Stearns (wstearns@pobox.com). Mason, Buildkernel, named2hosts,
and ipfwadm2ipchains are at: http://www.pobox.com/~wstearns/
--------------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:26 EST