dg50@daimlerchrysler.com wrote:
>> The user makes a few selections that reflect at
>> a high level what hardware he has, and the server tool builds a little
>> custom tarball that contains just the sources needed to compile a kernel
>> for that user.
> The idea I was going to work on before (before getting truly frightened
> at the magic involved in the kernel config stuff) was a CGI to select
> hardware, choose boot device (to build in that support, although making
> an initrd would have been simple enough), select kernel ver, and put in
> an email address.
> That config got put into a queue of kernels to build (saving only the
> built modules and kernel binary into a .tar.gz once the build is done)
> and once their .tar.gz was done, the person was emailed notification
> along with the location.
That's even sexier - but there's a host of problems with it:
1) The end user doesn't have the source available to play with - any of it.
The intent behind my idea was not to isolate a kernel "consumer" from the
build process, but only to restrict the amount of bandwidth consumed by
downloads, and the amount of storage space consumed by the local
/usr/src/linux filesysytem.
2) Isolating the consumer from the build process means they don't get to
see the little compile-time buglets that sometimes creep in to production
kernel sources - which means they don't get an opportunity to either report
or fix the bug themselves. As well, a given kernel developer may send a
given user a little mini-patch to see if that fixes a reported problem.
Downloading a custom precompiled kernel doesn't give the user the ability
to work with developers to fix problems like they do now. Anything that
interferes with the current development process is BAD.
3) In many cases, you cannot specify the hardware at a fine-grained level
up front. I have a recent example - my cable modem came with a D-Link PCI
ethernet card. There is no D-Link Model (whatever it was) option in the
"make fooconfig" menus. What I wound up doing was peeling a little label
off a chip on the card, and grep-ing the ethernet card drivers for what
appeared to be the main chip on the card - which matched a comment in
nec_2000.c - and then I compiled that option in AND DIDN'T HAVE TO GO
PESTERING Linux.kernel or whatever. Anything that limits people's abilities
to help themselves is BAD.
4) Building a kernel is a fairly resource-intensive activity, even for
powerful machines. Scale that kernel building service by World Domination -
who's going to pay for the hardware? Especially when this is already done
on a massively distributed computing basis, by having people compile their
own kernels?
It seems like a step backward.
However, the problem that needs to be solved "for a given user-stated
option list, what source files apply" is identical in both cases.
It should be stated that "my" tool is not a newbie-handling tool; it's a
bandwidth and storage space optimiser. The idea is do only download and
store the minimum set of sources that you need to build your particular
kernel - and nothing else.
Incidently, the current patch system does not meet this requirement. The
current patch system provides deltas between full source trees, not deltas
between current system requirements.
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/
____________________________________________________________________
Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com.
-
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:25 EST