[ Thursday, January 13, 2000 ] dg50@daimlerchrysler.com wrote:
> Here's the idea I have: create a user-space, server-based tool with a
> simple API and protocol that sits on top of an uncompressed kernel source
> tree. This server-based tool is talked to by a client (it could be a CGI
> program, or a desktop program, or a Java applet or whatever) that presents
> a little menu to the user. 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. Ideally, it should also touch the "make fooconfig" files
> just enough so that options that require sources that are not provided in
> the custom tarball are greyed out or not selectable.
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.
With that done, it should be ultra-easy to mirror (and adding in the
logic to spawn these off to machines willing to help donate CPU and keep
kernel src around would be nice) and then you can use the existing tricks
from kernel.org and create compile.<country>.kernel.org
Sadly very open to abuse/attack and with the kernel config complexity
(Even what's shown to a user) it may take some nifty DHTML to get it
done with a single page (multi-page could just get silly, but might be
a good starting point.
The main idea, though, is that if we're going to try and hide real
development away from the "normal" users, we might as well only feed
them binary kernels and modules anyway :) Not as "secure" as having the
src local and building yourself, but 1) easy for PHB types 2) can get
kernel compilations going on very fast machines 3) might open a chance
for a distributed approach 4) could allow caching of modules built
for previous config's if no relevant (non-trivial to check, for sure)
config changes exist.
Thoughts?
James
-- Miscellaneous Engineer --- IBM Netfinity Performance Development- 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:24 EST