[lkml]   [2000]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Userland Kernel Download Tool
    [ Thursday, January 13, 2000 ] 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 and create compile.<country>

    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.


    Miscellaneous Engineer --- IBM Netfinity Performance Development

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:55    [W:0.022 / U:96.880 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site