Re: [PATCH] make: add modules_update target

[Dustin Kirkland <dustin.kirkland@us.ibm.com>]

On Fri, 2006-04-14 at 13:02 -0400, Theodore Ts'o wrote: 
> This works as long as the .config hasn't been changed so that some
> configuration options haven't been changed so that a driver which had
> been previously built as a module is now built into the kernel.  In
> that case, you really want to make sure the no-longer applicable .ko
> file has been removed from the system.  If the developer knows that to
> be true, they can use your proposed modules_update without any problems.
> 
> As a suggestion, something that might be worth trying would be to
> change to modules_install so that it uses cp -u, but also so that it
> tries to delete all files that could have previously installed as
> modules (by using the obj-y list).  This should hopefully speed up
> modules_install, and make it do the right thing all the time.

Ted-

So I found the obj-y list a little tough to work with, as the objects
listed there do not contain fully qualified paths describing their
locations.

Here's another approach...

What you would think of some logic such that 

        if .config file has changed since last modules_install
                call normal brute force modules_install target
        else
                call this new, more efficient modules_update target
        
I was looking through the top level Makefile for a flag or some such
that would determine if a .config file has changed since last build, to
no avail.

It would be pretty easy to maintain an md5sum/sha1sum signature of
the .config used to perform a modules install/update (.config.md5), and
compare the signature of the current .conf with the previous to
determine change.

It looks like it may not be easy to drop in modules_update as a more
efficient alternative to modules_install, but note that is not the patch
that Kylie submitted...  

I suggest that it might be sufficient to document modules_update as a
handy, more efficient development build target when someone is working
on one particular module-built aspect of the kernel.  And clearly note
that to perform a full, clean /lib/modules/`uname -r`/kernel
synchronization with a given build tree, the more thorough
modules_install target is preferred.

Thoughts?

:-Dustin