lkml.org 
[lkml]   [2009]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [REGRESSION] Recent change to kernel spikes out ccache/distcc
    From
    Date
    On Tue, 2009-01-06 at 10:15 -0500, Theodore Ts'o wrote:
    > The following commit, ad7a953c, "kbuild: strip generated symbols from
    > *.ko" which was merged to the mainline last week (December 28th) has the
    > unfortunate side effct of making ccache useless. That's because all
    > files are now built using a two step process. First they are compiled
    > to assembly via "gcc -S -o .tmp_foo.s" and then assembled via "gcc" in a
    > separate step. Unfortunately, ccache doesn't seem to be able to cache
    > either the compilation or the assembly step (and it may not be worth it
    > once the two steps are separated).
    >
    > It would be nice if there was a CONFIG option which compiles files the
    > old-fashioned way, even if we lose the ability to strip the__crc_
    > symbols, just so that ccache can function again, since it can really
    > speed up the kernel development process. Alternatively, maybe ccache
    > could somehow be taught a specialized way take the .c file, some kind of
    > kbuild-specified version identifier, and then output of the gcc -S,
    > assembly frobnication, gcc -c, objcopy pipeline that kbuild uses to
    > build an object file, so we can have cache the entire kbuild object
    > building process.
    >
    > Or, if that's too complicated, maybe it would be worthwhile to have
    > kbuild create its own specialized ccache system? Note that the last two
    > solutions rule out using distcc, unless we can encapsulate the build
    > process from a series of Makefile macros to a shell or C program, which
    > could then be injected to the remote host system to be executed by
    > distcc. One value of doing that is the CRC or MD5 of the shell script
    > could be used as the version tag for the cache system.
    >
    > In the short term, though, it would be nice if we could get back a
    > simple way of making a kernel object file using just cc, so that ccache
    > and distcc could be functional again. Does that seem reasonable?

    So what's the current status on this, could we get it reverted ASAP or
    add that CONFIG_ switch (default N)?

    Leaving the build system broken for so long just isn't cool.



    \
     
     \ /
      Last update: 2009-01-14 18:19    [W:4.241 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site