Re: [PATCH] split UTS_RELEASE to a separate header.

[Brian Gerst <bgerst@xxxxxxxxxxxxx>]

Michael S. Tsirkin wrote:
> Hello!
> Quoting r. Sam Ravnborg (sam@xxxxxxxxxxxx) "Re: changing local version requires full rebuild":
>
> > On Sun, Jan 16, 2005 at 05:22:42PM +0200, Michael S. Tsirkin wrote:
> >
> > > Hi!
> > > Is it just me, or does changing the local version always require
> > > a full kernel rebuild?
> > >
> > > If so, I'd like to fix it, since I like copying
> > > my kernel source with --preserve and changing the
> > > local version, then going back to the old version in case of
> > > a crash.
> > > Its important to change the local version to force 
> > > make install and make modules_install to put things in a separate
> > > directory.
> >
> > Just tried it out here.
> > After cp -Ra only a limited part of the kernel rebuilds.
> > o oiu.c in ieee directory - because it dependson the shell script
> > o A number of drivers that include version.h
> > 	- This should be changed so local version does not affect
> > 	  the reast of version.h.
> > o Other stuff that is always build if kernel has changed
> >
> > Do you use "echo -mylocalver > localversion" to change the local version?
> >
> > 	Sam
>
>
> Well, we have
> /usr/src/linux-2.6.10-gold # grep -l UTS_RELEASE -rI . | wc -l
> 29
> grep -l version.h -rI . | fgrep -v .cmd | fgrep -v '.mod' | fgrep -e '.c' -e '.h' | wc -l
> 354
>
> This means that about 300 files are compiled each time localversion changes,
> which do not actually use the local version.
>
> So, let us split UTS_RELEASE to a separate header: release.h
> The following patch over 2.6.10 does that, and fixed the in-tree files that
> really need to include it.
> Works for me, and helps me cut down compilation time. Comments?

Most of the stuff using UTS_RELEASE can use system_utsname.release 
instead (except boot code).  Most cases in drivers/ can simply be removed.

--
				Brian Gerst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/