On 23:34 Thu 10 Sep 2020, Masahiro Yamada wrote: >On Thu, Sep 10, 2020 at 8:57 PM Rasmus Villemoes > wrote: >> >> When building for an embedded target using Yocto, we're sometimes >> observing that the version string that gets built into vmlinux (and >> thus what uname -a reports) differs from the path under /lib/modules/ >> where modules get installed in the rootfs, but only in the length of >> the -gabc123def suffix. Hence modprobe always fails. >> >> The problem is that Yocto has the concept of "sstate" (shared state), >> which allows different developers/buildbots/etc. to share build >> artifacts, based on a hash of all the metadata that went into building >> that artifact - and that metadata includes all dependencies (e.g. the >> compiler used etc.). That normally works quite well; usually a clean >> build (without using any sstate cache) done by one developer ends up >> being binary identical to a build done on another host. However, one >> thing that can cause two developers to end up with different builds >> [and thus make one's vmlinux package incompatible with the other's >> kernel-dev package], which is not captured by the metadata hashing, is >> this `git describe`: The output of that can be affected by >> >> (1) git version: before 2.11 git defaulted to a minimum of 7, since >> 2.11 (git.git commit e6c587) the default is dynamic based on the >> number of objects in the repo >> (2) hence even if both run the same git version, the output can differ >> based on how many remotes are being tracked (or just lots of local >> development branches or plain old garbage) >> (3) and of course somebody could have a core.abbrev config setting in >> ~/.gitconfig >> >> So in order to avoid `uname -a` output relying on such random details >> of the build environment which are rather hard to ensure are >> consistent between developers and buildbots, use an explicit >> --abbrev=15 option (and for consistency, also use rev-parse --short=15 >> for the unlikely case of no signed tags being usable). >> >> Now, why is 60 bits enough for everyone? It's not mathematically >> guaranteed that git won't have to use 16 in some git repo, but it is >> beyond unlikely: Even in a repo with 100M objects, the probability >> that any given commit (i.e. the one being described) clashes with some >> other object in the first 15 hex chars is less than 1e-10, and >> currently a git repo tracking Linus', -stable and -rt only has around >> 10M objects. > > >I agree that any randomness should be avoided. > >My question is, do we need 15-digits? > > >The kernelrelease is formed by >[kernel version] + [some digits of git hash]. > > >For example, "git describe" shows as follows: > >v5.9.0-rc4-00034-g7fe10096c150 > > >Linus gives a new tag every week (or every two week). > > >So, I think the conflict happens >only when we have two commits that start with the same 7-digits >in the _same_ release. Is this correct? > >We have 14000 - 15000 commits in each release, >not 100M. > > I kinda agree with this...we need to chopped down the excess bits from the information . Indeed , a 15 digits is too long to keep up. ~Bhaskar > > >> >> Signed-off-by: Rasmus Villemoes >> --- >> I could probably fix things by adding a 'git config --local >> core.abbrev 15' step to the Yocto build process after the repo to >> build from has been cloned but before building has started. But in the >> interest of binary reproducibility outside of just Yocto builds, I >> think it's better if this lives in the kernel. >> >> scripts/setlocalversion | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/scripts/setlocalversion b/scripts/setlocalversion >> index 20f2efd57b11..c5262f0d953d 100755 >> --- a/scripts/setlocalversion >> +++ b/scripts/setlocalversion >> @@ -45,7 +45,7 @@ scm_version() >> >> # Check for git and a git repo. >> if test -z "$(git rev-parse --show-cdup 2>/dev/null)" && >> - head=$(git rev-parse --verify --short HEAD 2>/dev/null); then >> + head=$(git rev-parse --verify --short=15 HEAD 2>/dev/null); then >> >> # If we are at a tagged commit (like "v2.6.30-rc6"), we ignore >> # it, because this version is defined in the top level Makefile. >> @@ -59,7 +59,7 @@ scm_version() >> fi >> # If we are past a tagged commit (like >> # "v2.6.30-rc5-302-g72357d5"), we pretty print it. >> - if atag="$(git describe 2>/dev/null)"; then >> + if atag="$(git describe --abbrev=15 2>/dev/null)"; then >> echo "$atag" | awk -F- '{printf("-%05d-%s", $(NF-1),$(NF))}' >> >> # If we don't have a tag at all we print -g{commitish}. >> -- >> 2.23.0 >> > > >-- >Best Regards >Masahiro Yamada