Re: Userland Kernel Download Tool

From: dg50@daimlerchrysler.com
Date: Tue Jan 18 2000 - 12:20:49 EST


"Matthew D. Pitts" <mpitts@xoommail.com> said:
>> dg50@daimlerchrysler.com wrote:
>> > Sitting on my /usr/src partition is a great big whalloping hunk of
data -
>> > the Linux kernel sources. Of that data, only a very small part of it
is
>> > actually used in the production of the kernel for my machine. Most of
that
>> > space is wasted.

>> No argument from most of us here.

> OTOH, it is convenient for the developers to have everything together in
> one piece, not a collection of separate pieces that have to be kept in sync
> and that cause problems because "I downloaded core-2.6.20 today,

Complete and utter agreement. Any scheme that requires users to download multiple tarballs invites the possibility of mis-syncing and thus much
confusion.

Thus, the tool that would provide the capability for partial-tree downloads
must handle all the metaconfiguration stuff. It must, without fail, given a
current kernel source tree and a list of desired subsystems, provide every
single required source file - and it must do so transparent to both users
and (more importantly) developers.

> If not developing/looking at the
> kernel, get your distribution's kernel. They did the work of cutting down
> the source for you, and that is part of what you paid for.

This isn't necessarily a valid option - what if an important bugfix or
security hole is patched in the latest production kernel? The distributions
don't move all that quickly. What about "prosumer" users; users who don't
develop themselves, but who download/compile/test kernels from the
development tree? There were quite a few of these around the 2.1.9x
timeframe.

This is not a "newbie handler" - this is a bandwidth reducer/storage space
reducer.

> This has been hashed to death a good many times to much already, look it up
> in the archives of the list.

But the problem has never been _solved_. All that the previous discussion has done is set conditions and parameters; ie: "multiple tarballs are no
good" etc,

With regards to rsync - I haven't looked at this, but from the sounds of
it, this is a tool to keep a remote and local filesystem in sync. Sounds
good on the surface, but how is it configured? Does it require explicit
file lists on either the server or the client? If so, who maintains the
lists? How does it handle the case where a new file is added to an existing
tree? The devil isn't in the transport, it's in the configuration.

I had a quick look at buildkernel - interesting idea. It suffers from being
client-based though - a major change in the way the kernel source is
organized would break the script, and with the script residing on the
client, you have no control over it. However, there's no reason why a
buildkernel-like client tool couldn't talk to the server-based bit through
an API that would remain stable.

It appears to me that the first step is coming up with something that can
parse the current kernel config stuff, and build a usable data structure
from it. Once you have that, all kinds of magic becomes available.

So, Linux::Kernel::Config.pm is the first step.

Anybody have a quick overview of how the kernel config stuff works?

DG

-
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 : Sun Jan 23 2000 - 21:00:18 EST