linux-kernel - Re: Linux 2.6.32-rc3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <alpine.LFD.2.00.0910061311460.7229@localhost.localdomain>
Date:	Tue, 06 Oct 2009 13:40:44 -0400 (EDT)
From:	Len Brown <lenb@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Dirk Hohndel <hohndel@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.32-rc3

Both Ingo and Dirk clarified and amplified my original request,
that it be easy to trivially tell the difference between stuff
_based on_ on 2.6.X, and stuff _based on_ the following merge window.

I fully understand non-linear development, I undersatnd
and use CONFIG_LOCALVERSION_AUTO, but that isn't sufficient
to solve the problem I have in my use case.

In my use-case, I develop on my desktop with a backing git tree.

When I want to do builds, I throw a tar-ball over the wall
to a remote compute engine to chew on the tree for a few hours.

The compute engine runs a relatively time-consuming serialized
script to discover all of the interesting configs to build.
It then stores those configs in a unique place associated
with that release.  It doesn't have a backing git tree,
so it uses the info in the Makefile -- 2.6.X.

Then the compute engine builds each config, and stores the
output in the same place -- 2.6.X.  On a typical build error,
I fix, send a new tar file, and unless I've changed Kconfig,
I kick off the builds without re-generating all the config files.

Even if I could get it, I generally don't want an exact -g1234
to identify the release, because 90% of the time I want to re-use
the config files that I've already built for the snapshot
the tree is based on without the repeating the time-consuming config
re-generation step.

My big problem today is that is that the new 2.6.X results
overwrites my reference configs for the real 2.6.X.

This means that if I have a development tree that is based
on the real 2.6.X (I almost always do), as soon as I build
a merge window kernel, I've lost all the golden configs
that I may want to re-use for my branch that is based
on the real 2.6.X

This also means that I've overwritten all of the
reference build results.

Maybe this use-case is stupid and simple-minded, but I'm
sure there are more stupid and more simple-minded use cases
out there that would benefit from immediately knowing the
difference in the Makefile between something based on 2.6.X
and something based on the following merge window.

thanks for listening.

-Len

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