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 ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel