* [patch] kbuild: improve version string logic
@ 2010-01-04 21:31 David Rientjes
2010-01-05 13:59 ` Michal Marek
0 siblings, 1 reply; 20+ messages in thread
From: David Rientjes @ 2010-01-04 21:31 UTC (permalink / raw)
To: Michal Marek; +Cc: Ingo Molnar, Linus Torvalds, linux-kernel
The LOCALVERSION= string passed to "make" will now always be appended to
the kernel version after CONFIG_LOCALVERSION, if it exists, regardless of
whether CONFIG_LOCALVERSION_AUTO is set or not. This allows users to
uniquely identify their kernel builds with a string.
scripts/setlocalversion will now always be called to determine whether
the repository is beyond a tagged (release) commit. When at a tagged
commit, this script will now suppress all output.
If CONFIG_LOCALVERSION_AUTO is enabled, the unique SCM tag reported by
setlocalversion (or .scmversion) is appended to the kernel version, if it
exists. When CONFIG_LOCALVERSION_AUTO is not enabled, a `+' is appended
to the kernel version to represent that the kernel has been revised since
the last release unless "make LOCALVERSION=" was used to uniquely identify
the build.
The end result is this:
- when LOCALVERSION= is passed to "make", it is appended to the kernel
version,
- when CONFIG_LOCALVERSION_AUTO is enabled, a unique SCM identifier is
appended if the respository has been revised beyond a tagged commit,
and
- when CONFIG_LOCALVERSION_AUTO is disabled, a `+' is appended if the
repository has been revised beyond a tagged commit and LOCALVERSION=
was not passed to "make".
Examples:
With CONFIG_LOCALVERSION_AUTO: "make" results in
v2.6.32-rc4-00149-ga3ccf63. If there are uncommited changes to the
respository, it results in v2.6.32-rc4-00149-ga3ccf63-dirty. If
"make LOCALVERSION=kbuild" were used, it results in
v2.6.32-rc4-kbuild-00149-ga3ccf63-dirty.
Without CONFIG_LOCALVERSION_AUTO, "make" results in v2.6.32-rc4+
unless the repository is at the Linux v2.6.32-rc4 commit (in which
case the version would be v2.6.32-rc4). If "make LOCALVERSION=kbuild"
were used, it results in v2.6.32-rc4-kbuild.
Also renames variables such as localver-auto and _localver-auto to more
accurately describe what they represent: localver-extra and
scm-identifier, respectively.
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: David Rientjes <rientjes@google.com>
---
Makefile | 43 +++++++++++++++++++++++++++----------------
scripts/setlocalversion | 3 ++-
2 files changed, 29 insertions(+), 17 deletions(-)
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -898,14 +898,19 @@ $(vmlinux-dirs): prepare scripts
# $(localver)
# localversion* (files without backups, containing '~')
# $(CONFIG_LOCALVERSION) (from kernel config setting)
-# $(localver-auto) (only if CONFIG_LOCALVERSION_AUTO is set)
-# ./scripts/setlocalversion (SCM tag, if one exists)
-# $(LOCALVERSION) (from make command line if provided)
+# $(LOCALVERSION) (from make command line, if provided)
+# $(localver-extra)
+# $(scm-identifier) (unique SCM tag, if one exists)
+# ./scripts/setlocalversion (only with CONFIG_LOCALVERSION_AUTO)
+# .scmversion (only with CONFIG_LOCALVERSION_AUTO)
+# + (only without CONFIG_LOCALVERSION_AUTO
+# and without LOCALVERSION= and
+# repository is at non-tagged commit)
#
-# Note how the final $(localver-auto) string is included *only* if the
-# kernel config option CONFIG_LOCALVERSION_AUTO is selected. Also, at the
-# moment, only git is supported but other SCMs can edit the script
-# scripts/setlocalversion and add the appropriate checks as needed.
+# For kernels without CONFIG_LOCALVERSION_AUTO compiled from an SCM that has
+# been revised beyond a tagged commit, `+' is appended to the version string
+# when not overridden by using "make LOCALVERSION=". This indicates that the
+# kernel is not a vanilla release version and has been modified.
pattern = ".*/localversion[^~]*"
string = $(shell cat /dev/null \
@@ -914,26 +919,32 @@ string = $(shell cat /dev/null \
localver = $(subst $(space),, $(string) \
$(patsubst "%",%,$(CONFIG_LOCALVERSION)))
-# If CONFIG_LOCALVERSION_AUTO is set scripts/setlocalversion is called
-# and if the SCM is know a tag from the SCM is appended.
-# The appended tag is determined by the SCM used.
+# scripts/setlocalversion is called to create a unique identifier if the source
+# is managed by a known SCM and the repository has been revised since the last
+# tagged (release) commit. The format of the identifier is determined by the
+# SCM's implementation.
#
# .scmversion is used when generating rpm packages so we do not loose
# the version information from the SCM when we do the build of the kernel
# from the copied source
-ifdef CONFIG_LOCALVERSION_AUTO
-
ifeq ($(wildcard .scmversion),)
- _localver-auto = $(shell $(CONFIG_SHELL) \
+ scm-identifier = $(shell $(CONFIG_SHELL) \
$(srctree)/scripts/setlocalversion $(srctree))
else
- _localver-auto = $(shell cat .scmversion 2> /dev/null)
+ scm-identifier = $(shell cat .scmversion 2> /dev/null)
endif
- localver-auto = $(LOCALVERSION)$(_localver-auto)
+ifdef CONFIG_LOCALVERSION_AUTO
+ localver-extra = $(scm-identifier)
+else
+ ifneq ($scm-identifier,)
+ ifeq ($(LOCALVERSION),)
+ localver-extra = +
+ endif
+ endif
endif
-localver-full = $(localver)$(localver-auto)
+localver-full = $(localver)$(LOCALVERSION)$(localver-extra)
# Store (new) KERNELRELASE string in include/config/kernel.release
kernelrelease = $(KERNELVERSION)$(localver-full)
diff --git a/scripts/setlocalversion b/scripts/setlocalversion
--- a/scripts/setlocalversion
+++ b/scripts/setlocalversion
@@ -26,7 +26,8 @@ if head=`git rev-parse --verify --short HEAD 2>/dev/null`; then
# 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
- echo "$atag" | awk -F- '{printf("-%05d-%s", $(NF-1),$(NF))}'
+ echo "$atag" | awk -F- 'int($(NF-1)) > 0 \
+ {printf("-%05d-%s", $(NF-1),$(NF))}'
# If we don't have a tag at all we print -g{commitish}.
else
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch] kbuild: improve version string logic
2010-01-04 21:31 [patch] kbuild: improve version string logic David Rientjes
@ 2010-01-05 13:59 ` Michal Marek
2010-01-05 14:11 ` Stephen Rothwell
2010-01-13 21:01 ` David Rientjes
0 siblings, 2 replies; 20+ messages in thread
From: Michal Marek @ 2010-01-05 13:59 UTC (permalink / raw)
To: David Rientjes
Cc: Ingo Molnar, Linus Torvalds, linux-kernel, Stephen Rothwell
On 4.1.2010 22:31, David Rientjes wrote:
> The LOCALVERSION= string passed to "make" will now always be appended to
> the kernel version after CONFIG_LOCALVERSION, if it exists, regardless of
> whether CONFIG_LOCALVERSION_AUTO is set or not. This allows users to
> uniquely identify their kernel builds with a string.
>
> scripts/setlocalversion will now always be called to determine whether
> the repository is beyond a tagged (release) commit. When at a tagged
> commit, this script will now suppress all output.
>
> If CONFIG_LOCALVERSION_AUTO is enabled, the unique SCM tag reported by
> setlocalversion (or .scmversion) is appended to the kernel version, if it
> exists. When CONFIG_LOCALVERSION_AUTO is not enabled, a `+' is appended
> to the kernel version to represent that the kernel has been revised since
> the last release unless "make LOCALVERSION=" was used to uniquely identify
> the build.
>
> The end result is this:
>
> - when LOCALVERSION= is passed to "make", it is appended to the kernel
> version,
>
> - when CONFIG_LOCALVERSION_AUTO is enabled, a unique SCM identifier is
> appended if the respository has been revised beyond a tagged commit,
> and
>
> - when CONFIG_LOCALVERSION_AUTO is disabled, a `+' is appended if the
> repository has been revised beyond a tagged commit and LOCALVERSION=
> was not passed to "make".
I've read the thread from last October where this was discussed
(http://thread.gmane.org/gmane.linux.kernel/897768/focus=898233). I'm
not entirely sure if all people will be happy about the plus sign that
can't be turned off, but from the thread I got the impression that the
plus sign is wanted, so let's add this to linux-next now, so that people
doing automated builds can adjust their scripts if needed. Just in case:
Stephen, won't this break your linux-next scripts in any way? The final
build won't change, because of the next-YYYYMMDD tag, but the builds in
between will have the '+' appended to their version.
Two small comments are below.
> Examples:
>
> With CONFIG_LOCALVERSION_AUTO: "make" results in
> v2.6.32-rc4-00149-ga3ccf63. If there are uncommited changes to the
> respository, it results in v2.6.32-rc4-00149-ga3ccf63-dirty. If
> "make LOCALVERSION=kbuild" were used, it results in
> v2.6.32-rc4-kbuild-00149-ga3ccf63-dirty.
>
> Without CONFIG_LOCALVERSION_AUTO, "make" results in v2.6.32-rc4+
> unless the repository is at the Linux v2.6.32-rc4 commit (in which
> case the version would be v2.6.32-rc4). If "make LOCALVERSION=kbuild"
> were used, it results in v2.6.32-rc4-kbuild.
>
> Also renames variables such as localver-auto and _localver-auto to more
> accurately describe what they represent: localver-extra and
> scm-identifier, respectively.
>
> Acked-by: Ingo Molnar <mingo@elte.hu>
> Signed-off-by: David Rientjes <rientjes@google.com>
> ---
> Makefile | 43 +++++++++++++++++++++++++++----------------
> scripts/setlocalversion | 3 ++-
> 2 files changed, 29 insertions(+), 17 deletions(-)
>
> diff --git a/Makefile b/Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -898,14 +898,19 @@ $(vmlinux-dirs): prepare scripts
> # $(localver)
> # localversion* (files without backups, containing '~')
> # $(CONFIG_LOCALVERSION) (from kernel config setting)
> -# $(localver-auto) (only if CONFIG_LOCALVERSION_AUTO is set)
> -# ./scripts/setlocalversion (SCM tag, if one exists)
> -# $(LOCALVERSION) (from make command line if provided)
> +# $(LOCALVERSION) (from make command line, if provided)
$(LOCALVERSION) is no longer part of $(localver), it should be indented
at the same level.
> +# $(localver-extra)
> +# $(scm-identifier) (unique SCM tag, if one exists)
> +# ./scripts/setlocalversion (only with CONFIG_LOCALVERSION_AUTO)
> +# .scmversion (only with CONFIG_LOCALVERSION_AUTO)
> +# + (only without CONFIG_LOCALVERSION_AUTO
> +# and without LOCALVERSION= and
> +# repository is at non-tagged commit)
> #
> -# Note how the final $(localver-auto) string is included *only* if the
> -# kernel config option CONFIG_LOCALVERSION_AUTO is selected. Also, at the
> -# moment, only git is supported but other SCMs can edit the script
> -# scripts/setlocalversion and add the appropriate checks as needed.
> +# For kernels without CONFIG_LOCALVERSION_AUTO compiled from an SCM that has
> +# been revised beyond a tagged commit, `+' is appended to the version string
> +# when not overridden by using "make LOCALVERSION=". This indicates that the
> +# kernel is not a vanilla release version and has been modified.
>
> pattern = ".*/localversion[^~]*"
> string = $(shell cat /dev/null \
> @@ -914,26 +919,32 @@ string = $(shell cat /dev/null \
> localver = $(subst $(space),, $(string) \
> $(patsubst "%",%,$(CONFIG_LOCALVERSION)))
>
> -# If CONFIG_LOCALVERSION_AUTO is set scripts/setlocalversion is called
> -# and if the SCM is know a tag from the SCM is appended.
> -# The appended tag is determined by the SCM used.
> +# scripts/setlocalversion is called to create a unique identifier if the source
> +# is managed by a known SCM and the repository has been revised since the last
> +# tagged (release) commit. The format of the identifier is determined by the
> +# SCM's implementation.
> #
> # .scmversion is used when generating rpm packages so we do not loose
> # the version information from the SCM when we do the build of the kernel
> # from the copied source
> -ifdef CONFIG_LOCALVERSION_AUTO
> -
> ifeq ($(wildcard .scmversion),)
> - _localver-auto = $(shell $(CONFIG_SHELL) \
> + scm-identifier = $(shell $(CONFIG_SHELL) \
> $(srctree)/scripts/setlocalversion $(srctree))
> else
> - _localver-auto = $(shell cat .scmversion 2> /dev/null)
> + scm-identifier = $(shell cat .scmversion 2> /dev/null)
> endif
>
> - localver-auto = $(LOCALVERSION)$(_localver-auto)
> +ifdef CONFIG_LOCALVERSION_AUTO
> + localver-extra = $(scm-identifier)
> +else
> + ifneq ($scm-identifier,)
> + ifeq ($(LOCALVERSION),)
> + localver-extra = +
> + endif
> + endif
> endif
>
> -localver-full = $(localver)$(localver-auto)
> +localver-full = $(localver)$(LOCALVERSION)$(localver-extra)
>
> # Store (new) KERNELRELASE string in include/config/kernel.release
> kernelrelease = $(KERNELVERSION)$(localver-full)
> diff --git a/scripts/setlocalversion b/scripts/setlocalversion
> --- a/scripts/setlocalversion
> +++ b/scripts/setlocalversion
> @@ -26,7 +26,8 @@ if head=`git rev-parse --verify --short HEAD 2>/dev/null`; then
> # 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
> - echo "$atag" | awk -F- '{printf("-%05d-%s", $(NF-1),$(NF))}'
> + echo "$atag" | awk -F- 'int($(NF-1)) > 0 \
> + {printf("-%05d-%s", $(NF-1),$(NF))}'
>
> # If we don't have a tag at all we print -g{commitish}.
> else
Why is this needed? There is
# 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.
if [ -z "`git describe --exact-match 2>/dev/null`" ]; then
a few lines above and even without your patch ./scripts/setlocalversion
returns nothing when HEAD is tagged. Do you have an old git version that
doesn't undestand --exact-match? In that case, the if around this should
be removed.
thanks,
Michal
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch] kbuild: improve version string logic
2010-01-05 13:59 ` Michal Marek
@ 2010-01-05 14:11 ` Stephen Rothwell
2010-01-13 21:01 ` David Rientjes
1 sibling, 0 replies; 20+ messages in thread
From: Stephen Rothwell @ 2010-01-05 14:11 UTC (permalink / raw)
To: Michal Marek; +Cc: David Rientjes, Ingo Molnar, Linus Torvalds, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 578 bytes --]
Hi Michal,
On Tue, 05 Jan 2010 14:59:11 +0100 Michal Marek <mmarek@suse.cz> wrote:
>
> Stephen, won't this break your linux-next scripts in any way? The final
> build won't change, because of the next-YYYYMMDD tag, but the builds in
> between will have the '+' appended to their version.
I think it should be OK - I don't depend on the kernel version for
anything until the very end. If it does cause a problem, I am now
forwarned and can fix my scripts.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* [patch] kbuild: improve version string logic
2010-01-05 13:59 ` Michal Marek
2010-01-05 14:11 ` Stephen Rothwell
@ 2010-01-13 21:01 ` David Rientjes
2010-01-16 6:37 ` Ingo Molnar
1 sibling, 1 reply; 20+ messages in thread
From: David Rientjes @ 2010-01-13 21:01 UTC (permalink / raw)
To: Michal Marek; +Cc: Ingo Molnar, Linus Torvalds, Stephen Rothwell, linux-kernel
The LOCALVERSION= string passed to "make" will now always be appended to
the kernel version after CONFIG_LOCALVERSION, if it exists, regardless of
whether CONFIG_LOCALVERSION_AUTO is set or not. This allows users to
uniquely identify their kernel builds with a string.
If CONFIG_LOCALVERSION_AUTO is enabled, the unique SCM tag reported by
setlocalversion (or .scmversion) is appended to the kernel version, if it
exists. When CONFIG_LOCALVERSION_AUTO is not enabled, a `+' is appended
to the kernel version to represent that the kernel has been revised since
the last release unless "make LOCALVERSION=" was used to uniquely identify
the build.
The end result is this:
- when LOCALVERSION= is passed to "make", it is appended to the kernel
version,
- when CONFIG_LOCALVERSION_AUTO is enabled, a unique SCM identifier is
appended if the respository has been revised beyond a tagged commit,
and
- when CONFIG_LOCALVERSION_AUTO is disabled, a `+' is appended if the
repository has been revised beyond a tagged commit and LOCALVERSION=
was not passed to "make".
Examples:
With CONFIG_LOCALVERSION_AUTO: "make" results in
v2.6.32-rc4-00149-ga3ccf63. If there are uncommited changes to the
respository, it results in v2.6.32-rc4-00149-ga3ccf63-dirty. If
"make LOCALVERSION=kbuild" were used, it results in
v2.6.32-rc4-kbuild-00149-ga3ccf63-dirty.
Without CONFIG_LOCALVERSION_AUTO, "make" results in v2.6.32-rc4+
unless the repository is at the Linux v2.6.32-rc4 commit (in which
case the version would be v2.6.32-rc4). If "make LOCALVERSION=kbuild"
were used, it results in v2.6.32-rc4-kbuild.
Also renames variables such as localver-auto and _localver-auto to more
accurately describe what they represent: localver-extra and
scm-identifier, respectively.
Signed-off-by: David Rientjes <rientjes@google.com>
---
Makefile | 43 +++++++++++++++++++++++++++----------------
1 files changed, 27 insertions(+), 16 deletions(-)
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -908,14 +908,19 @@ endif
# $(localver)
# localversion* (files without backups, containing '~')
# $(CONFIG_LOCALVERSION) (from kernel config setting)
-# $(localver-auto) (only if CONFIG_LOCALVERSION_AUTO is set)
-# ./scripts/setlocalversion (SCM tag, if one exists)
-# $(LOCALVERSION) (from make command line if provided)
+# $(LOCALVERSION) (from make command line, if provided)
+# $(localver-extra)
+# $(scm-identifier) (unique SCM tag, if one exists)
+# ./scripts/setlocalversion (only with CONFIG_LOCALVERSION_AUTO)
+# .scmversion (only with CONFIG_LOCALVERSION_AUTO)
+# + (only without CONFIG_LOCALVERSION_AUTO
+# and without LOCALVERSION= and
+# repository is at non-tagged commit)
#
-# Note how the final $(localver-auto) string is included *only* if the
-# kernel config option CONFIG_LOCALVERSION_AUTO is selected. Also, at the
-# moment, only git is supported but other SCMs can edit the script
-# scripts/setlocalversion and add the appropriate checks as needed.
+# For kernels without CONFIG_LOCALVERSION_AUTO compiled from an SCM that has
+# been revised beyond a tagged commit, `+' is appended to the version string
+# when not overridden by using "make LOCALVERSION=". This indicates that the
+# kernel is not a vanilla release version and has been modified.
pattern = ".*/localversion[^~]*"
string = $(shell cat /dev/null \
@@ -924,26 +929,32 @@ string = $(shell cat /dev/null \
localver = $(subst $(space),, $(string) \
$(patsubst "%",%,$(CONFIG_LOCALVERSION)))
-# If CONFIG_LOCALVERSION_AUTO is set scripts/setlocalversion is called
-# and if the SCM is know a tag from the SCM is appended.
-# The appended tag is determined by the SCM used.
+# scripts/setlocalversion is called to create a unique identifier if the source
+# is managed by a known SCM and the repository has been revised since the last
+# tagged (release) commit. The format of the identifier is determined by the
+# SCM's implementation.
#
# .scmversion is used when generating rpm packages so we do not loose
# the version information from the SCM when we do the build of the kernel
# from the copied source
-ifdef CONFIG_LOCALVERSION_AUTO
-
ifeq ($(wildcard .scmversion),)
- _localver-auto = $(shell $(CONFIG_SHELL) \
+ scm-identifier = $(shell $(CONFIG_SHELL) \
$(srctree)/scripts/setlocalversion $(srctree))
else
- _localver-auto = $(shell cat .scmversion 2> /dev/null)
+ scm-identifier = $(shell cat .scmversion 2> /dev/null)
endif
- localver-auto = $(LOCALVERSION)$(_localver-auto)
+ifdef CONFIG_LOCALVERSION_AUTO
+ localver-extra = $(scm-identifier)
+else
+ ifneq ($scm-identifier,)
+ ifeq ($(LOCALVERSION),)
+ localver-extra = +
+ endif
+ endif
endif
-localver-full = $(localver)$(localver-auto)
+localver-full = $(localver)$(LOCALVERSION)$(localver-extra)
# Store (new) KERNELRELASE string in include/config/kernel.release
kernelrelease = $(KERNELVERSION)$(localver-full)
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch] kbuild: improve version string logic
2010-01-13 21:01 ` David Rientjes
@ 2010-01-16 6:37 ` Ingo Molnar
2010-01-16 7:34 ` Stephen Rothwell
0 siblings, 1 reply; 20+ messages in thread
From: Ingo Molnar @ 2010-01-16 6:37 UTC (permalink / raw)
To: David Rientjes, Andrew Morton
Cc: Michal Marek, Linus Torvalds, Stephen Rothwell, linux-kernel
* David Rientjes <rientjes@google.com> wrote:
> The LOCALVERSION= string passed to "make" will now always be appended to the
> kernel version after CONFIG_LOCALVERSION, if it exists, regardless of
> whether CONFIG_LOCALVERSION_AUTO is set or not. This allows users to
> uniquely identify their kernel builds with a string.
I've been using Linus's earlier patch for 3 months meanwhile in -tip and the
'+' version string differentiator is very useful in practice. Your version of
the patch should address some of the observations offered in the original
discussion as well. Would be nice to have your patch upstream (in the next
merge window or so).
Given that Sam doesnt maintain the kbuild tree anymore, would this patch be a
good fit for -mm perhaps?
Ingo
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch] kbuild: improve version string logic
2010-01-16 6:37 ` Ingo Molnar
@ 2010-01-16 7:34 ` Stephen Rothwell
2010-01-16 9:26 ` Ingo Molnar
0 siblings, 1 reply; 20+ messages in thread
From: Stephen Rothwell @ 2010-01-16 7:34 UTC (permalink / raw)
To: Ingo Molnar
Cc: David Rientjes, Andrew Morton, Michal Marek, Linus Torvalds,
linux-kernel
[-- Attachment #1: Type: text/plain, Size: 378 bytes --]
Hi Ingo,
On Sat, 16 Jan 2010 07:37:54 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> Given that Sam doesnt maintain the kbuild tree anymore, would this patch be a
> good fit for -mm perhaps?
There is a new kbuild tree maintainer: Michal Marek <mmarek@suse.cz>
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch] kbuild: improve version string logic
2010-01-16 7:34 ` Stephen Rothwell
@ 2010-01-16 9:26 ` Ingo Molnar
2010-01-18 9:40 ` Michal Marek
0 siblings, 1 reply; 20+ messages in thread
From: Ingo Molnar @ 2010-01-16 9:26 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Rientjes, Andrew Morton, Michal Marek, Linus Torvalds,
linux-kernel
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Ingo,
>
> On Sat, 16 Jan 2010 07:37:54 +0100 Ingo Molnar <mingo@elte.hu> wrote:
> >
> > Given that Sam doesnt maintain the kbuild tree anymore, would this patch be a
> > good fit for -mm perhaps?
>
> There is a new kbuild tree maintainer: Michal Marek <mmarek@suse.cz>
Good. Michal, what do you think about David's patch?
Ingo
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch] kbuild: improve version string logic
2010-01-16 9:26 ` Ingo Molnar
@ 2010-01-18 9:40 ` Michal Marek
2010-01-18 10:45 ` David Rientjes
0 siblings, 1 reply; 20+ messages in thread
From: Michal Marek @ 2010-01-18 9:40 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, David Rientjes, Andrew Morton, Linus Torvalds,
linux-kernel
On 16.1.2010 10:26, Ingo Molnar wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Hi Ingo,
>>
>> On Sat, 16 Jan 2010 07:37:54 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>>>
>>> Given that Sam doesnt maintain the kbuild tree anymore, would this patch be a
>>> good fit for -mm perhaps?
>>
>> There is a new kbuild tree maintainer: Michal Marek <mmarek@suse.cz>
>
> Good. Michal, what do you think about David's patch?
The patch is OK, I already commented on a previous version and this
addresses the two minor issues I had. I was just too busy last week to
apply it. I will do so ASAP now.
Michal
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch] kbuild: improve version string logic
2010-01-18 9:40 ` Michal Marek
@ 2010-01-18 10:45 ` David Rientjes
2010-01-18 11:15 ` Michal Marek
0 siblings, 1 reply; 20+ messages in thread
From: David Rientjes @ 2010-01-18 10:45 UTC (permalink / raw)
To: Michal Marek
Cc: Ingo Molnar, Stephen Rothwell, Andrew Morton, Linus Torvalds,
linux-kernel
On Mon, 18 Jan 2010, Michal Marek wrote:
> >>> Given that Sam doesnt maintain the kbuild tree anymore, would this patch be a
> >>> good fit for -mm perhaps?
> >>
> >> There is a new kbuild tree maintainer: Michal Marek <mmarek@suse.cz>
> >
> > Good. Michal, what do you think about David's patch?
>
> The patch is OK, I already commented on a previous version and this
> addresses the two minor issues I had. I was just too busy last week to
> apply it. I will do so ASAP now.
>
Michal, where are you hosting your git tree? Are you going to be taking
over kbuild-next on git.kernel.org?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch] kbuild: improve version string logic
2010-01-18 10:45 ` David Rientjes
@ 2010-01-18 11:15 ` Michal Marek
2010-01-18 15:53 ` Jiri Kosina
0 siblings, 1 reply; 20+ messages in thread
From: Michal Marek @ 2010-01-18 11:15 UTC (permalink / raw)
To: David Rientjes
Cc: Ingo Molnar, Stephen Rothwell, Andrew Morton, Linus Torvalds,
linux-kernel
On 18.1.2010 11:45, David Rientjes wrote:
> Michal, where are you hosting your git tree? Are you going to be taking
> over kbuild-next on git.kernel.org?
git://repo.or.cz/linux-kbuild.git for-next
(http://repo.or.cz/w/linux-kbuild.git). Maybe I should ask for an
account in git.kernel.org account and move it there, you're not the
first one to wonder where to find the tree :).
Michal
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch] kbuild: improve version string logic
2010-01-18 11:15 ` Michal Marek
@ 2010-01-18 15:53 ` Jiri Kosina
0 siblings, 0 replies; 20+ messages in thread
From: Jiri Kosina @ 2010-01-18 15:53 UTC (permalink / raw)
To: Michal Marek
Cc: David Rientjes, Ingo Molnar, Stephen Rothwell, Andrew Morton,
Linus Torvalds, linux-kernel
On Mon, 18 Jan 2010, Michal Marek wrote:
> > Michal, where are you hosting your git tree? Are you going to be taking
> > over kbuild-next on git.kernel.org?
>
> git://repo.or.cz/linux-kbuild.git for-next
> (http://repo.or.cz/w/linux-kbuild.git). Maybe I should ask for an
> account in git.kernel.org account and move it there, you're not the
> first one to wonder where to find the tree :).
Yes, I think it is preferred.
I know, I know, the proper URL is listed in MAINTAINERS file ... still, I
believe that what most people do when looking for particular git tree is
going to http://git.kernel.org/ and looking around there.
So having the tree there really helps to give it much more exposure than
on some random git hosting.
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Linux 2.6.32-rc3
@ 2009-10-05 0:44 Linus Torvalds
2009-10-06 1:57 ` Len Brown
0 siblings, 1 reply; 20+ messages in thread
From: Linus Torvalds @ 2009-10-05 0:44 UTC (permalink / raw)
To: Linux Kernel Mailing List
Yes, it's really -rc3, because I'm skipping -rc2 entirely.
Or not "entirely". As too many people pointed out, I had been somewhat
less than careful, and the 2.6.32-rc1 release actually called itself -rc2
in the Makefile. As a result, I don't want to make a 2.6.32-rc2 release,
since any bug-reports etc would then be met with the inevitable confusion:
do you mean -rc2 as in the Makefile (ie really -rc1) or -rc2 as in the
tagged release.
So I'm avoiding that confusion entirely, and consider the -rc1 release to
have also been -rc2, and thus a week later we're now at -rc3. And let's
hope that I won't have that particular "senior moment" any more. Although
I'm sure I can screw up releases some other way.
Anyway. On to the actual changes. It's actually been fairly calm,
although I'm not sure exactly why. Regardless, I'm not going to complain,
or look the gift horse in the mouth. The shortlog is appended (quite
often, the -rc2 shortlogs are still big enough that I skip them).
The biggest change in the diff is the e1000 network driver update, but the
bulk of that is actually just whitespace changes thanks to running it
through lindent along with dropping dead PCIe code (the PCIe support is in
the e1000e driver).
Apart from that single driver update (which is almost 60% of the diffs),
there's a fair number of one-liners, but also some DRM updates (mainly the
experimental radeon driver but also a capability to specify modes etc),
some pcmcia and serial updates, ext4 and btrfs, etc. With a smattering of
ACPI, sound and network code to fill in the cracks.
The appended shortlog probably gives a reasonable view into it, but one
thing that might be worth mention (despite being fairly small) is that
there's been some IO latency tweaking in the block layer (CFS scheduler).
I'm hoping that ends up being one of those noticeable things, where people
might actually notice better responsiveness. Give it a try.
Linus
---
Aaro Koskinen (1):
iop3xx: ATU and PCI memory configuration corrected
Adam Jackson (4):
drm/edid: const cleanup
drm/edid: Ignore bad standard timings.
drm/edid: Detailed standard timing blocks have six timings, not five.
drm/edid: Fix standard timing parse for EDID <= 1.2
Ajay Kumar Gupta (1):
omap: Add missing mux pin for EHCI phy reset line
Ajit Khaparde (1):
be2net: Workaround to fix a bug in Rx Completion processing.
Alan Jenkins (3):
sony-laptop: Don't unregister the SPIC driver if it wasn't registered
sony-laptop: check for rfkill hard block at load time
sony-laptop: re-read the rfkill state when resuming from suspend
Albert Herranz (1):
sdio: pass whitelisted cis funce tuples to sdio drivers
Alex Chiang (1):
ACPI: dock: fix "sibiling" typo
Alex Deucher (5):
drm/radeon/kms/r600: clamp vram to aperture size
drm/radeon/kms: fix some bugs in vline reloc
drm/radeon/kms/r600: add support for vline relocs
drm/radeon/kms/r600: fix forcing pci mode on agp cards
drm/radeon/r600: fix offset handling in CS parser
Alexander Beregalov (1):
cciss: fix build when !PROC_FS
Alexey Dobriyan (4):
cpqarray: switch to seq_file
dac960: switch to seq_file
const: constify remaining file_operations
headers: remove sched.h from poll.h
Alexey Starikovskiy (3):
ACPI: EC: Restart command even if no interrupts from EC
ACPI: EC: Rewrite DMI checks
ACPI: EC: Don't parse DSDT for EC early init on Compal
Amerigo Wang (1):
drm: create gitignore file for radeon
Andrew Morton (3):
net/ipv4/tcp.c: fix min() type mismatch warning
drivers/input/input.c: fix CONFIG_PM=n warning
revert "m68k: convert to asm-generic/hardirq.h"
Andrew Patterson (3):
cciss: Remove sysfs entries for logical drives on driver cleanup.
cciss: Use one scan thread per controller and fix hang during rmmod
cciss: Allow triggering of rescan of logical drive topology via sysfs entry
Andy Spencer (1):
sscanf(): fix %*s%n
Angelo Arrifano (2):
omap: Fix wrong jtag_id for 850
omap: Fix a OMAP_MPUIO_VBASE typo for 850
Anton Vorontsov (1):
3c59x: Rework suspend and resume
Arjan van de Ven (5):
net: Add explicit bound checks in net/socket.c
wext: Add bound checks for copy_from_user
x86: Provide an alternative() based cmpxchg64()
ACPI: Fix bound checks for copy_from_user in the acpi /proc code
SFI: remove __init from sfi_verify_table
Atis Elsts (1):
net: Use sk_mark for routing lookup in more places
Atsushi Nemoto (1):
serial_txx9: use container_of() instead of direct cast
Barry Song (1):
ASoC: fix kconfig order of Blackfin drivers
Ben Dooks (11):
s3cmci: use resource_size() instead of local macro
s3cmci: update probe to use new platform id list
s3cmci: change GPIO to gpiolib from S3C24XX specific calls
s3cmci: change to use dev_pm_ops
s3cmci: fix direct write to interrupt mask
s3cmci: add debugfs support for examining driver and hardware state
s3cmci: add SDIO IRQ support
s3cmci: Kconfig selection for PIO/DMA/Both
s3cmci: DMA fixes
s3cmci: make SDIO IRQ hardware IRQ support build-time configurable
s3cmci: add better support for no card detect or write protect available
Ben Greear (1):
ixgbe patch to provide NIC's tx/rx counters via ethtool
Bjorn Helgaas (1):
ACPI: fix bus scanning memory leaks
Breno Leitao (1):
icom: convert space to tabs
Chaithrika U S (1):
ASoC: DaVinci: Correct McASP FIFO initialization
Choi, David (1):
drivers/net: ks8851_mll ethernet network driver
Chris Ball (2):
Btrfs: Fix setting umask when POSIX ACLs are not enabled
Btrfs: Use CONFIG_BTRFS_POSIX_ACL to enable ACL code
Chris Mason (1):
Btrfs: take i_mutex before generic_write_checks
Christian Lamparter (1):
ar9170: fix bug in iq-auto calibration value calculation
Christoph Hellwig (5):
Btrfs: fix arguments to btrfs_wait_on_page_writeback_range
Btrfs: remove duplicates of filemap_ helpers
block: use normal I/O path for discard requests
block: allow large discard requests
afs: remove cache.h
Chuck Ebbert (1):
serial: add parameter to force skipping the test for the TXEN bug
Cliff Cai (1):
ASoC: Blackfin: fix inverted handling of SPORT0 on PORT F/G
Curt Wohlgemuth (3):
ext4: Make sure ext4_dirty_inode() updates the inode in no journal mode
ext4: Handle nested ext4_journal_start/stop calls without a journal
ext4: Fix build warning in ext4_dirty_inode()
Dan Williams (2):
iop33x: update defconfig (default atu to on)
iop: downgrade maintenance status
Daniel T Chen (3):
ALSA: hda - Add HP Pavilion dv4t-1300 to MSI whitelist
ALSA: intel8x0 - Mute External Amplifier by default for Sony VAIO VGN-T350P
ALSA: intel8x0 - Mute External Amplifier by default for Sony VAIO VGN-B1VP
Dave Airlie (11):
drm/radeon/kms: enable r600 tv outputs.
drm/radeon/kms: enable dac load detection by default.
drm/radeon/kms: don't require up to 64k allocations. (v2)
fb: change rules for global rules match.
drm/kms: start adding command line interface using fb.
drm/radeon/kms: remove unneeded master create/destroy functions.
drm/r600: get values from the passed in IB not the copy.
drm/kms: protect against fb helper not being created.
drm/radeon/kms: fix for the extra pages copying.
drm/kms: make fb helper work for all drivers.
drm/r600: fix memory leak introduced with 64k malloc avoidance fix.
David Brown (1):
ARM: 5739/1: ARM: allow empty ATAG_CORE
David S. Miller (1):
net: Make setsockopt() optlen be unsigned.
Dmitry Artamonow (1):
ARM: 5734/1: arm: fix compilation of entry-common.S for older CPUs
Don Skidmore (1):
e1000: cleanup unused prototype
Eric Dumazet (6):
sched_clock: Fix atomicity/continuity bug by using cmpxchg64()
net: Fix sock_wfree() race
net: restore tx timestamping for accelerated vlans
pktgen: Fix delay handling
tg3: Remove prev_vlan_tag from struct tx_ring_info
net: splice() from tcp to pipe should take into account O_NONBLOCK
Eric Sandeen (2):
ext4: drop ext4dev compat
ext4: retry failed direct IO allocations
Frank Mayhar (1):
ext4: Avoid updating the inode table bh twice in no journal mode
Frans Pop (1):
e1000e/igb/ixgbe: Don't report an error if devices don't support AER
Giuliano Pochini (1):
ALSA: echoaudio - Re-enable the line-out control for the Mia card
Greg Ungerer (1):
ARM: 5740/1: fix valid_phys_addr_range() range check
H Hartley Sweeten (1):
fs/bio.c: move EXPORT* macros to line after function
Hartley Sweeten (1):
ARM: 5735/1: sa1111: CodingStyle cleanups
Hirokazu Takata (5):
m32r: fix tme_handler
m32r: export delay loop symbols
m32r: define ioread* and iowrite* macros
m32r: add rtc_lock variable
m32r: Fix set_memory() for DISCONTIGMEM
Hiroshi DOYU (3):
omap: mailbox: Execute softreset at startup
omap: mailbox: Flush posted write when acking mailbox irq
omap: Fix wrong condition check in while loop for mailbox and iommu2
Huang Shijie (1):
mm/rmap.c: fix comment
Huang Weiyi (2):
MIPS: BCM63xx: Remove duplicated #include
MIPS: Remove duplicated #include
Igor Perminov (1):
mac80211: Fix [re]association power saving issue on AP side
Jan Kara (1):
ext4: Update documentation about quota mount options
Jarek Poplawski (1):
ax25: Fix possible oops in ax25_make_new
Jarkko Nikula (1):
omap: Fix MMC gpio_wp for BeagleBoard C2 and above
Jaswinder Singh Rajput (2):
ARM: Remove unused CONFIG SA1100_H3XXX
ARM: includecheck fix: mach-davinci, board-dm365-evm.c
Jean Delvare (12):
sound: Make keywest_driver static
net: Fix wrong sizeof
i2c: Move misc devices documentation
max6875: Discard obsolete detect method
ds2482: Discard obsolete detect method
ltc4215/ltc4245: Discard obsolete detect methods
leds: leds-pca9532 - Drop unused module parameters
Staging: IIO: tsl2561: Drop unused module parameters
mfd: AB3100 drop unused module parameters
i2c: Minor documentation update
i2c: Hide probe errors caused by ACPI resource conflicts
macintosh: Don't assume i2c device probing always succeeds
Jeff Hansen (1):
bridge: Fix double-free in br_add_if.
Jens Axboe (7):
cciss: cciss_host_attr_groups should be const
cfq-iosched: add a knob for desktop interactiveness
cfq-iosched: implement slower async initiate and queue ramp up
cfq-iosched: rename 'desktop' sysfs entry to 'low_latency'
cfq-iosched: use assigned slice sync value, not default
cfq-iosched: don't delay async queue if it hasn't dispatched at all
Revert "Seperate read and write statistics of in_flight requests"
Jerome Glisse (2):
drm/radeon/kms: Convert RV515 to new init path and associated cleanup
drm/radeon/kms: Convert R520 to new init path and associated cleanup
Jesse Brandeburg (12):
e1000: drop dead pcie code from e1000
e1000: remove unused functions
e1000: use netif_tx_disable
e1000: stop timers at appropriate times
e1000: test link state conclusively
e1000: fix tx waking queue after queue stopped during shutdown
e1000: two workarounds were incomplete, fix them
e1000: remove races when changing mtu
e1000: drop redunant line of code, cleanup
e1000: updated whitespace and comments
e1000: drop unused functionality for eeprom write/read
e1000: fix namespacecheck warnings
Jiri Pirko (2):
ixgbe: correct the parameter description
bonding: set primary param via sysfs
Jiri Slaby (1):
Char: vt_ioctl, fix BKL imbalance
Joe Perches (1):
MAINTAINERS: ARM/Palm file patterns
Johannes Berg (5):
cfg80211: wext: don't display BSSID unless associated
cfg80211: don't set privacy w/o key
cfg80211: always get BSS
mac80211: improve/fix mlme messages
wext: add back wireless/ dir in sysfs for cfg80211 interfaces
John Fastabend (3):
net: fix vlan_get_size to include vlan_flags size
net: fix nlmsg len size for skb when error bit is set.
net: fix double skb free in dcbnl
Josef Bacik (2):
Btrfs: proper -ENOSPC handling
Btrfs: fix data space leak fix
Josh Stone (1):
ext4: Add a stub for mpage_da_data in the trace header
Jouni Malinen (1):
mac80211_hwsim: Fix initial beacon timer configuration
Juha Leppanen (1):
atm: dereference of he_dev->rbps_virt in he_init_group()
Julia Lawall (3):
arch/arm/plat-iop: Use DIV_ROUND_CLOSEST
Btrfs: introduce missing kfree
MIPS: SMTC: Remove duplicate structure field initialization
Jun'ichi Nomura (1):
Add a tracepoint for block request remapping
KAMEZAWA Hiroyuki (4):
memcg: fix refcnt going negative
cgroup: catch bad css refcnt at css_put
memcg: some modification to softlimit under hierarchical memory reclaim.
memcg: reduce check for softlimit excess
Kevin Cernekee (1):
MIPS: MIPSxx SC: Avoid destructive invalidation on partial L2 cachelines.
Kirill A. Shutemov (2):
ARM: 5727/1: Pass IFSR register to do_PrefetchAbort()
ARM: 5728/1: Proper prefetch abort handling on ARMv6 and ARMv7
Len Brown (1):
acpi_pad: build only on X86
Leo Chen (2):
ARM: 5732/1: remove redundant include file
ARM: 5733/1: fix bcmring compile error
Linus Torvalds (4):
Revert "x86, mce: do not compile mcelog message on AMD"
pty: reconnect the BSD TIOCSPTLCK handling to legacy ptys
tty: Avoid dropping ldisc_mutex over hangup tty re-initialization
Linux 2.6.32-rc3
Linus Walleij (2):
ARM: 5731/2: Fix U300 generic GPIO, remove ifdefs from MMCI v3
ARM: 5738/1: Correct TCM documentation
Lukasz Marcinowski (1):
ALSA: hda - CD-audio sound for hda-intel conexant benq laptop
Manoj Iyer (1):
ALSA: hda - Added quirk to enable sound on Toshiba NB200
Mark Mason (1):
MIPS: Sibyte: Fix compilation error.
Mark Salter (1):
mn10300: fix kernel build failures when using gcc-4.x
Martin K. Petersen (3):
block: Set max_sectors correctly for stacking devices
block: Do not clamp max_hw_sectors for stacking devices
block: Topology ioctls
Mattia Dongili (3):
sony-laptop: remove device_ctrl and the SPIC mini drivers
sony-laptop: SPIC unset IRQF_SHARED, set IRQF_DISABLED
sony-laptop: remove _INI call at init time
Maxime Bizon (2):
MIPS: BCM63xx: Add serial driver for bcm63xx integrated UART.
MIPS: BCM63xx: Add PCMCIA & Cardbus support.
Michael Buesch (1):
b43: Always use block-I/O for the PIO data registers
Michael Chan (1):
cnic: Fix NETDEV_UP event processing.
Michal Schmidt (1):
skge: use unique IRQ name
Michal Szalata (1):
rt2x00: Thrustmaster FunAccess WIFI USB and rt73usb
Miguel de Barros (1):
ALSA: hda - Analog Devices AD1984A add HP Touchsmart model
Mikael Pettersson (2):
drm: fix drm_fb_helper warning when !CONFIG_MAGIC_SYSRQ
drm: fix radeon DRM warnings when !CONFIG_DEBUG_FS
Mike Frysinger (1):
asm-generic/gpio.h: pull in linux/kernel.h for might_sleep()
Mike McCormack (1):
skge: Make sure both ports initialize correctly
Mingming Cao (4):
ext4: release reserved quota when block reservation for delalloc retry
ext4: Split uninitialized extents for direct I/O
ext4: Use end_io callback to avoid direct I/O fallback to buffered I/O
ext4: async direct IO for holes and fallocate support
OGAWA Hirofumi (2):
fat/nls: Fix handling of utf8 invalid char
fat: Check s_dirt in fat_sync_fs()
Ori Finkelman (1):
IPv4 TCP fails to send window scale option when window scale is zero
Paul Mundt (1):
module: fix up CONFIG_KALLSYMS=n build.
Paul Wise (1):
vfat: change the default from shortname=lower to shortname=mixed
Peter P Waskiewicz Jr (4):
ixgbe: Fix disabling of relaxed ordering with Tx DCA
ixgbe: Fix backplane flow control autoneg
ixgbe: Bump driver version number
ixgbe: Remove ATR computation for UDP traffic
Philipp Reisner (8):
connector: Keep the skb in cn_callback_data
connector: Provide the sender's credentials to the callback
connector/dm: Fixed a compilation warning
connector: Removed the destruct_data callback since it is always kfree_skb()
dm/connector: Only process connector packages from privileged processes
dst/connector: Disallow unpliviged users to configure dst
pohmelfs/connector: Disallow unpliviged users to configure pohmelfs
uvesafb/connector: Disallow unpliviged users to send netlink packets
Rafael J. Wysocki (2):
PM / PCMCIA: Drop second argument of pcmcia_socket_dev_suspend()
PM / yenta: Fix cardbus suspend/resume regression
Rakib Mullick (1):
SFI: fix section mismatch warnings in sfi_core.c
Ralf Baechle (11):
ax25: Add missing dev_put in ax25_setsockopt
MIPS: BCM1480: Re-apply patch lost due to bad resolution of merge conflict.
MIPS: SMP: Fix build.
MIPS: SMP: Inline arch_send_call_function_{single_ipi,ipi_mask}
MIPS: Sibyte: Get rid of BKL.
MIPS: Excite: Get rid of BKL.
MIPS: VPE: Fix build after the credential changes a while ago.
MIPS: VPE: Get rid of BKL.
MIPS: Avoid spurious make includecheck message
NET: mkiss: Fix typo
Kconfig: STRIP: Remove stale bits of STRIP help text
Randy Dunlap (3):
isdn: fix netjet/isdnhdlc build errors
cciss: fix schedule_timeout() parameters
docs: update patch size in SubmittingPatches
Reinette Chatre (3):
iwlwifi: fix debugfs buffer handling
iwlwifi: fix memory leak in command queue handling
iwlwifi: fix 3945 ucode info retrieval after failure
Richard Röjfors (1):
uartlite: allow building for timberdale MFD
Roel Kluin (4):
MIPS: Decrease size of au1xxx_dbdma_pm_regs[][]
MIPS: MSP71xx: request_irq() failure ignored in msp_pcibios_config_access()
cyclades: fix read buffer overflow
serial167: fix read buffer overflow
Roland Dreier (1):
ACPI: kill overly verbose "throttling states" log messages
Ron Mercer (5):
qlge: Fix bad bit definitions.
qlge: Fix out of sync hardware semaphore.
qlge: Fix spin_lock warning.
qlge: Protect reset recovery with rtnl_lock().
qlge: Fix error exit for probe call.
Russell King (9):
ARM: Fix section mismatch warning in Integrator pci_v3
ARM: Fix SA1100 Assabet/Neponset PCMCIA section mismatch warnings
ARM: Fix SA1100 Neponset serial section mismatch
ARM: Fix SA11x0 clocksource warning
ARM: Fix warning: #warning syscall migrate_pages not implemented
ARM: Fix warning: unused variable 'highmem'
ARM: Don't allow highmem on SMP platforms without h/w TLB ops broadcast
ARM: Fix __cpuexit section mismatch warnings
ARM: Ensure do_cache_op takes mmap_sem
Ryusuke Konishi (2):
nilfs2: fix missing zero-fill initialization of btree node cache
nilfs2: fix missing initialization of i_dir_start_lookup member
Rémi Denis-Courmont (1):
Phonet: fix mutex imbalance
Sage Weil (2):
Btrfs: fix error cases for ioctl transactions
Btrfs: fix deadlock with free space handling and user transactions
Samuel Thibault (1):
x86: fix csum_ipv6_magic asm memory clobber
Sanjeev Premi (1):
omap: iovmm: Fix compiler warning
Sascha Hauer (3):
spi-imx: update state correctly
spi-imx: fix initial chipselect settings
spi-imx: setup mode_bits we can handle
Sascha Hlusiak (2):
Revert "sit: stateless autoconf for isatap"
sit: fix off-by-one in ipip6_tunnel_get_prl
Shaohua Li (1):
ACPI: create Processor Aggregator Device driver
Stephen Hemminger (1):
sky2: irqname based on pci address
Stephen M. Cameron (17):
cciss: Remove some unused code in rebuild_lun_table()
cciss: Dynamically allocate struct device for each logical drive as needed.
cciss: Rearrange logical drive sysfs code to make the "changing a disk" path work.
cciss: Handle failure of blk_init_queue gracefully in cciss_add_disk.
cciss: Handle cases when cciss_add_disk fails.
cciss: Handle special case for sysfs attributes of the first logical drive.
cciss: Clear all sysfs-exposed data for deleted logical drives.
cciss: Fix usage_count check in rebuild_lun_table when triggered via sysfs.
cciss: Fix excessive gendisk freeing bug on driver unload.
cciss: Silence noisy per-disk messages output by cciss_read_capacity
cciss: Preserve all 8 bytes of LUN ID for logical drives.
cciss: Don't check h->busy_initializing in cciss_open().
cciss: Add lunid attribute to each logical drive in /sys
cciss: fix some magic numbers in the raid-level decoding
cciss: Add a "raid_level" attribute to each logical drive in /sys
cciss: Add usage_count attribute to each logical drive in /sys
cciss: Dynamically allocate the drive_info_struct for each logical drive.
Suresh Jayaraman (1):
swapfile: avoid NULL pointer dereference in swapon when s_bdev is NULL
Sven Eckelmann (1):
ALSA: ctxfi: Swapped SURROUND-SIDE mute
Takashi Iwai (7):
ALSA: hda - Resurrect input-source mixer of ALC268 model=acer
ALSA: Don't assume i2c device probing always succeeds
ASoC: Fix dependency of CONFIG_SND_PXA2XX_SOC_IMOTE2
ALSA: hda - Fix digita/analog mic auto-switching with IDT codecs
ALSA: hda - Fix / improve ALC66x parser
ALSA: Fix invalid __exit in sound/mips/*.c
ALSA: usb - Use strlcat() correctly
Tejun Heo (6):
percpu: fix unit_map[] verification in pcpu_setup_first_chunk()
percpu: make pcpu_build_alloc_info() clear static buffers
sparc64: implement page mapping percpu first chunk allocator
percpu: make embedding first chunk allocator check vmalloc space size
percpu: make pcpu_setup_first_chunk() failures more verbose
percpu: make allocation failures more verbose
Theodore Ts'o (9):
ext4: Use ext4_msg() for ext4_da_writepage() errors
ext4: Fix hueristic which avoids group preallocation for closed files
ext4: Adjust ext4_da_writepages() to write out larger contiguous chunks
ext4: EXT4_IOC_MOVE_EXT: Check for different original and donor inodes first
ext4, jbd2: Drop unneeded printks at mount and unmount time
ext4: Use tracepoints for mb_history trace file
jbd2: Use tracepoints for history file
ext4: Fix time encoding with extra epoch bits
ext4: fix a BUG_ON crash by checking that page has buffers attached to it
Tobias Klauser (1):
omap: rng: Use resource_size instead of manual calculation
Tony Lindgren (4):
omap: Fix compile for arch/arm/mach-omap2
omap: Fix mcspi compile for 2420
omap: Fix 44xx compile
omap: Fix matrix_keymap_data usage
Toshihiro HANAWA (1):
m32r: Fix IPI function calls for SMP
Troy Kisky (2):
ASoC: DaVinci: Fix divide by zero error during 1st execution
ASoC: Davinci: Fix race with cpu_dai->dma_data
Uwe Kleine-König (8):
MIPS: Loongson2: Fix typo "enalbe" -> "enable"
don't use __devexit_p to wrap meth_remove
don't use __devexit_p to wrap sgiseeq_remove
move virtnet_remove to .devexit.text
spi-imx: rename source file to spi_imx.c
spi-imx: no need to assert bits_per_word being initialized
spi-imx: initialize complete config struct
spi-imx: strip down chipselect function to only drive the chipselect
Vivek Goyal (1):
cfq-iosched: delay async IO dispatch, if sync IO was just done
Zdenek Kabelac (1):
Add missing blk_trace_remove_sysfs to be in pair with blk_trace_init_sysfs
roel kluin (1):
bcm63xx_enet: timeout off by one in do_mdio_op()
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Linux 2.6.32-rc3
2009-10-05 0:44 Linux 2.6.32-rc3 Linus Torvalds
@ 2009-10-06 1:57 ` Len Brown
2009-10-06 2:51 ` Dirk Hohndel
0 siblings, 1 reply; 20+ messages in thread
From: Len Brown @ 2009-10-06 1:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
> do you mean -rc2 as in the Makefile (ie really -rc1) or -rc2 as in the
> tagged release.
We have a similar problem with the period between, say, 2.6.X and
2.6.Y-rc1. The Makefile still says 2.6.X, yet during the 2.6.Y
merge window the tree is very different from 2.6.X.
This confuses things like my scripts that take a source tree tarball,
and (re)generate config files for build testing based on the tags
in the Makefile. There is no way for the scripts to know the
post 2.6.X tree not the same as 2.6.X itself, the new configs
overwrite the old, overwrite the old results etc.
I think that BenH also had troubles with this issue and pointed
it out a while back, but you were not convinced at the time that
it was a problem worth solving.
This could be clarified if you update Makefile on the 1st commit
after 2.6.X is frozen to simply be 2.6.Y-merge or 2.6.Y-rc0
or something. Anything but 2.6.X.
thanks,
-Len Brown, Intel Open Source Technolgy Center
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Linux 2.6.32-rc3
2009-10-06 1:57 ` Len Brown
@ 2009-10-06 2:51 ` Dirk Hohndel
2009-10-06 14:18 ` Linus Torvalds
0 siblings, 1 reply; 20+ messages in thread
From: Dirk Hohndel @ 2009-10-06 2:51 UTC (permalink / raw)
To: Len Brown; +Cc: Linus Torvalds, Linux Kernel Mailing List
On Mon, 2009-10-05 at 21:57 -0400, Len Brown wrote:
> > do you mean -rc2 as in the Makefile (ie really -rc1) or -rc2 as in the
> > tagged release.
>
> We have a similar problem with the period between, say, 2.6.X and
> 2.6.Y-rc1. The Makefile still says 2.6.X, yet during the 2.6.Y
> merge window the tree is very different from 2.6.X.
>
> This confuses things like my scripts that take a source tree tarball,
> and (re)generate config files for build testing based on the tags
> in the Makefile. There is no way for the scripts to know the
> post 2.6.X tree not the same as 2.6.X itself, the new configs
> overwrite the old, overwrite the old results etc.
>
> I think that BenH also had troubles with this issue and pointed
> it out a while back, but you were not convinced at the time that
> it was a problem worth solving.
>
> This could be clarified if you update Makefile on the 1st commit
> after 2.6.X is frozen to simply be 2.6.Y-merge or 2.6.Y-rc0
> or something. Anything but 2.6.X.
I have seen this request many times and it seems to make perfect sense.
The first commit applied after a release should change the version
number to "something" - and "2.6.next-rc0" sounds as good as anything
else that has been proposed so far.
/D
--
Dirk Hohndel
Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Linux 2.6.32-rc3
2009-10-06 2:51 ` Dirk Hohndel
@ 2009-10-06 14:18 ` Linus Torvalds
2009-10-06 14:44 ` Ingo Molnar
0 siblings, 1 reply; 20+ messages in thread
From: Linus Torvalds @ 2009-10-06 14:18 UTC (permalink / raw)
To: Dirk Hohndel; +Cc: Len Brown, Linux Kernel Mailing List
On Mon, 5 Oct 2009, Dirk Hohndel wrote:
> On Mon, 2009-10-05 at 21:57 -0400, Len Brown wrote:
>
> > This could be clarified if you update Makefile on the 1st commit
> > after 2.6.X is frozen to simply be 2.6.Y-merge or 2.6.Y-rc0
> > or something. Anything but 2.6.X.
>
> I have seen this request many times and it seems to make perfect sense.
No. It makes perfect sense just because the people who think so don't
think things through.
It doesn't help, for several reasons:
- the step function of the Makefile change happens once per release, and
if you compile anything but releases, you can never rely on just the
revision. Was it a plain -rc, a plain release, or something in
between? You'll never know, just looking at the 2.6.x.y thing.
In other words, you fundamentally have three choices:
(a) be confused. Adding an "-rc0" won't help. You'll still be confused
in between releases about exactly what you're running.
(b) use CONFIG_LOCALVERSION_AUTO=y
Now, if 'uname -r' says 2.6.31, then you _know_ it's exactly
2.6.31 and nothing else. If it's a few commits after 2.6.31, it
will say something like '2.6.31-1-g752015d', and you know that
it's one commit after 2.6.31, and you'll know _which_ commit it is!
(c) Don't compile anything but releases.
Those are the choices.
- An even _more_ fundamental reason: Linux development isn't linear.
There is not one "first commit" after a release, and there never will
be. Sure, there's a first commit that I do, but that has absolutely
zero relevance.
Learn this. Until you do, you'll be confused, and you'll show your
confusion by saying "I want a 2.6.n+1-rc0". You'll _also_ show your
confusion by things like "I was bisecting a bug that happened between
2.6.30 and 2.6.31, and suddenly git was asking me to test a kernel that
said it was version 2.6.29-rc1 - so I stopped bisecting because git was
confused".
Who was confused? Was it git, or was it the person who thought that the
Makefile version could be consistent in a non-linear world?
So no. I'm not going to do -rc0. Because doing that is _stupid_. And until
you understand _why_ it's stupid, it's pointless talking about it, and
when you _do_ understand that it's stupid, you'll agree with me.
Linus
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Linux 2.6.32-rc3
2009-10-06 14:18 ` Linus Torvalds
@ 2009-10-06 14:44 ` Ingo Molnar
2009-10-06 15:24 ` Linus Torvalds
0 siblings, 1 reply; 20+ messages in thread
From: Ingo Molnar @ 2009-10-06 14:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dirk Hohndel, Len Brown, Linux Kernel Mailing List
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> So no. I'm not going to do -rc0. Because doing that is _stupid_. And
> until you understand _why_ it's stupid, it's pointless talking about
> it, and when you _do_ understand that it's stupid, you'll agree with
> me.
I understand non-linear history, but still i think that it might make
sense to make it more apparent that the tree people pull from you after
.31 got released is a lot closer to what .32 is going to be than to .31.
(which the name implies)
I.e. i think it's a fact that right now our release version is highly
deceptive during the merge window. Two days into the merge window and we
have more commits added than we add from .31-rc7 to .31-rc9 total. A
week into the merge window we have .31 + 6000 commits merged and still
call it v2.6.31, to the casual looker.
We can ignore that and say "hehe, you dont understand non-linear trees
and ran git remote update blindly, too bad for you", or we might do
something to make things more transparent and reduce the confusion.
Personally i really want people to try our git trees, but them also be
fully aware of the risks involved.
One option would be to make LOCALVERSION_AUTO compulsory.
Or to add a tweak to the naming, something like:
v2.6.31
v2.6.31+
v2.6.32-rc1
v2.6.32-rc1+
..
v2.6.32-rc9
v2.6.32-rc9+
v2.6.32
Would make it clear what's going on, even in the simplified world of
limited-size version numbers.
Or, IMHO it would also be a valid naming model to do this small tweak to
the above naming scheme:
v2.6.31
v2.6.32-rc0
v2.6.32-rc0+
v2.6.32-rc1
v2.6.32-rc1+
..
v2.6.32-rc9
v2.6.32-rc9+
v2.6.32
... for the sole purpose of warning people that anything they pull after
v2.6.31 got released is (wildly!) not vanilla v2.6.31 anymore. Not more,
not less.
Am i confused? :-)
Ingo
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Linux 2.6.32-rc3
2009-10-06 14:44 ` Ingo Molnar
@ 2009-10-06 15:24 ` Linus Torvalds
2009-10-06 15:36 ` Ingo Molnar
0 siblings, 1 reply; 20+ messages in thread
From: Linus Torvalds @ 2009-10-06 15:24 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Dirk Hohndel, Len Brown, Linux Kernel Mailing List
On Tue, 6 Oct 2009, Ingo Molnar wrote:
>
> We can ignore that and say "hehe, you dont understand non-linear trees
> and ran git remote update blindly, too bad for you", or we might do
> something to make things more transparent and reduce the confusion.
You are missing the point.
The only thing we can do is to teach people that the Makefile version
isn't too important, and that it really doesn't tell very much.
Trying to tweak it to make it somehow "more meaningful" is a BAD THING,
because it continues to spoon-feed people a lie.
The cake is a lie. In between kernel versions, you can't rely on the
Makefile. You should teach yourself (and others) THAT, rather than trying
to teach people to believe the lie even more.
Once you start believing the lie, suddenly all the subtrees will start
thinking that now _their_ kernel versions are bad, so now they'll start to
want to make the same idiotic changes to their Makefiles, or maybe
they'll decide that they don't want to pull tagged releases, but the "one
after the tag so that they'll get the updated Makefile".
And even if they don't do that idiocy, the whole "the version number is
meaningful outside of releases" thing leads to brain damage.
> One option would be to make LOCALVERSION_AUTO compulsory.
Yes, I could live with that. If you're compiling from a git tree, we migth
as well show the real version.
It's the "let's make that meaningful and misleading number be even _more_
misleading by making people think it has meaning" magical thinking that I
hate.
It's wrong, and it leads people to believe in things that aren't true. I
refuse to cater to that kind of wrongheaded thinking.
I'd much rather screw up the version number entirely and add a _random_
number to it (so that the Makefile would say "2.6.18" after I have
released 2.6.32) just so that people would be forced to _understand_ that
the version number isn't as meaningful as you seem to think it is.
For example, let's take Arjan's request, that kerneloops should get -rc0.
Think about that for a few minutes. Really THINK about it. What happens?
[ Spend some time really thinking here. ]
What about people like all the networking guys who are running their
development kernels that haven't been merged yet? Their kernels won't say
-rc0. Are you going to ask them to do it too?
Or would you be better off teaching kerneloops about local versions?
Linus
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Linux 2.6.32-rc3
2009-10-06 15:24 ` Linus Torvalds
@ 2009-10-06 15:36 ` Ingo Molnar
2009-10-06 15:51 ` Linus Torvalds
0 siblings, 1 reply; 20+ messages in thread
From: Ingo Molnar @ 2009-10-06 15:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dirk Hohndel, Len Brown, Linux Kernel Mailing List
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Tue, 6 Oct 2009, Ingo Molnar wrote:
> >
> > We can ignore that and say "hehe, you dont understand non-linear
> > trees and ran git remote update blindly, too bad for you", or we
> > might do something to make things more transparent and reduce the
> > confusion.
>
> You are missing the point.
>
> The only thing we can do is to teach people that the Makefile version
> isn't too important, and that it really doesn't tell very much.
>
> Trying to tweak it to make it somehow "more meaningful" is a BAD
> THING, because it continues to spoon-feed people a lie.
>
> The cake is a lie. In between kernel versions, you can't rely on the
> Makefile. You should teach yourself (and others) THAT, rather than
> trying to teach people to believe the lie even more.
>
> Once you start believing the lie, suddenly all the subtrees will start
> thinking that now _their_ kernel versions are bad, so now they'll
> start to want to make the same idiotic changes to their Makefiles, or
> maybe they'll decide that they don't want to pull tagged releases, but
> the "one after the tag so that they'll get the updated Makefile".
>
> And even if they don't do that idiocy, the whole "the version number
> is meaningful outside of releases" thing leads to brain damage.
hm, i think you ignored (or missed, or found irrelevant) my first
suggested variant:
v2.6.31
v2.6.31+
v2.6.32-rc1
v2.6.32-rc1+
..
v2.6.32-rc9
v2.6.32-rc9+
v2.6.32
The '+' sign says that it's more than .31.
That defuses the 'lie' of trying to linerize a multi-thousand-node graph
down into some catchy human-readable string pretty efficiently i think.
It doesnt tell us precisely what that '+' means - it could be goodness
or it could be badness.
_That_ i think is a lot harder to confuse with the real .31 than a
v2.6.31-1234-g16123c4 version string.
My tweak #2, adding -rc0 indeed brings in problems, it's too artificial
to do it right after .31 gets released - and if we dont do it then we
cannot do it later either. (so we cannot really do it)
[ It might bring in some advantages too btw. A pull request to you for a
tree that is -rc0 based means it got rebased straight in the merge
window => bad. Such a thing would be apparent at a glance. 'Good'
trees should be based on some known good version of the previous
stable kernel cycle. ]
Ingo
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Linux 2.6.32-rc3
2009-10-06 15:36 ` Ingo Molnar
@ 2009-10-06 15:51 ` Linus Torvalds
2009-10-06 16:31 ` Linus Torvalds
0 siblings, 1 reply; 20+ messages in thread
From: Linus Torvalds @ 2009-10-06 15:51 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Dirk Hohndel, Len Brown, Linux Kernel Mailing List
On Tue, 6 Oct 2009, Ingo Molnar wrote:
>
> hm, i think you ignored (or missed, or found irrelevant) my first
> suggested variant:
No, I didn't ignore it, it just showed that you didn't know what you were
thinking about.
> v2.6.31
> v2.6.31+
>
> The '+' sign says that it's more than .31.
No. It shows no such thing. Because it DOES NOT EXIST in other peoples
trees until they rebase on top of mine.
Unless:
> _That_ i think is a lot harder to confuse with the real .31 than a
> v2.6.31-1234-g16123c4 version string.
.. are you saying that it would be just some automatically generated
thing, just a crippled form of CONFIG_LOCALVERSION_AUTO? Kind of a
CONFIG_LOCALVERSION_AUTO_SHORTFORM?
If so, then I don't hate "v2.6.31+", but at the same time, that single
plus-sign tells _so_much_ less than v2.6.31-1234-g16123c4 that I think
it's really sad and crippled.
Is it so hard to teach people what "v2.6.31-1234-g16123c4" means? It's not
like it's very complicated, and it's not like it's not visually very
distinct indeed from the tagged release case (which is just "v2.6.31").
I'd love to use "+" instead of "-", but I was thinking that there are
various version things that get unhappy about special characters like
that, so we've always used '-' as the separator (since we've always used
it).
So I'm _entirely_ open to changing how 'CONFIG_LOCALVERSION_AUTO' works,
or extending on that notion.
What I'm _not_ open to doing is to add made-up commits that change the
top-level Makefile at non-release points. Because that way really does lie
insanity.
Linus
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Linux 2.6.32-rc3
2009-10-06 15:51 ` Linus Torvalds
@ 2009-10-06 16:31 ` Linus Torvalds
2009-10-06 17:35 ` [patch] kbuild: Improve version string logic Ingo Molnar
0 siblings, 1 reply; 20+ messages in thread
From: Linus Torvalds @ 2009-10-06 16:31 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Dirk Hohndel, Len Brown, Linux Kernel Mailing List
On Tue, 6 Oct 2009, Linus Torvalds wrote:
>
> Unless:
>
> > _That_ i think is a lot harder to confuse with the real .31 than a
> > v2.6.31-1234-g16123c4 version string.
>
> .. are you saying that it would be just some automatically generated
> thing, just a crippled form of CONFIG_LOCALVERSION_AUTO? Kind of a
> CONFIG_LOCALVERSION_AUTO_SHORTFORM?
So how about this?
It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
way:
- if it is set, things work the way they always have, and you get a
extended kernel release like
2.6.32-rc3-00052-g0eca52a-dirty
- but if it is _not_ set, we'll still try to get a version from the
underlying SCM (we actually support git, hg and SVN right now, even if
some comments may say "git only"), and if the underlying SCM says it
has a local version, we append just "+", so you get a version number
like
2.6.32-rc3+
IOW, you'd never get 2.6.32-rc0, but you'd get either the complex git
version number (or SVN/hg/whatever), or at least "2.6.31+" with the "+"
showing that it is more than plain 2.6.31.
The "+" could be anything else, of course. The diff is pretty obvious, you
can argue about exactly _what_ you'd like to see as a suffix for "and then
some".
Linus
---
Makefile | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index e50569a..c62b7cc 100644
--- a/Makefile
+++ b/Makefile
@@ -963,8 +963,6 @@ localver = $(subst $(space),, $(string) \
# .scmversion is used when generating rpm packages so we do not loose
# the version information from the SCM when we do the build of the kernel
# from the copied source
-ifdef CONFIG_LOCALVERSION_AUTO
-
ifeq ($(wildcard .scmversion),)
_localver-auto = $(shell $(CONFIG_SHELL) \
$(srctree)/scripts/setlocalversion $(srctree))
@@ -972,7 +970,14 @@ else
_localver-auto = $(shell cat .scmversion 2> /dev/null)
endif
+ifdef CONFIG_LOCALVERSION_AUTO
localver-auto = $(LOCALVERSION)$(_localver-auto)
+else
+ ifeq ($_localver-auto,)
+ localver-auto = $(LOCALVERSION)
+ else
+ localver-auto = $(LOCALVERSION)+
+ endif
endif
localver-full = $(localver)$(localver-auto)
^ permalink raw reply related [flat|nested] 20+ messages in thread
* [patch] kbuild: Improve version string logic
2009-10-06 16:31 ` Linus Torvalds
@ 2009-10-06 17:35 ` Ingo Molnar
2009-10-06 18:37 ` Johannes Berg
2009-10-07 2:43 ` David Rientjes
0 siblings, 2 replies; 20+ messages in thread
From: Ingo Molnar @ 2009-10-06 17:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dirk Hohndel, Len Brown, Linux Kernel Mailing List
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Tue, 6 Oct 2009, Linus Torvalds wrote:
> >
> > Unless:
> >
> > > _That_ i think is a lot harder to confuse with the real .31 than a
> > > v2.6.31-1234-g16123c4 version string.
> >
> > .. are you saying that it would be just some automatically generated
> > thing, just a crippled form of CONFIG_LOCALVERSION_AUTO? Kind of a
> > CONFIG_LOCALVERSION_AUTO_SHORTFORM?
>
> So how about this?
this patch is great IMHO. I've modified it to propagate the '+' into the
long version string as well. I've tested it with auto-version not set
and it now gives:
Linux europe 2.6.32-rc3+ #2 SMP Tue Oct 6 19:26:58 CEST 2009 i686 i686 i386 GNU/Linux
the -rc3+ is a clearly visible distinction. This will improve things
when bugs are reported with LOCALVERSION_AUTO not set - we'll always
know when a tree is not vanilla.
With autoversion set 'uname -a' gives:
Linux europe 2.6.32-rc3+00052-g0eca52a-dirty #3 SMP Tue Oct 6 19:29:54 CEST 2009 i686 i686 i386 GNU/Linux
IMO that's intuitive too. We get whatever is described in the
localversion in addition to the tag. The '+' clearly signals that 'set
union' operation we've done.
So this patch solves all the problems i had with our versioning. I've
attached it below with a changelog.
Thanks,
Ingo
--------------->
Subject: kbuild: Improve version string logic
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 6 Oct 2009 09:31:03 -0700 (PDT)
It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
way:
- if it is set, things work the way they always have, and you get a
extended kernel release like:
2.6.32-rc3+00052-g0eca52a-dirty
( with the difference that the extra version string is separated via
'+' not via '-'. This improves visibility when we have additional
changes over a vanilla tag. )
- but if it is _not_ set, we'll still try to get a version from the
underlying SCM (we actually support git, hg and SVN right now, even if
some comments may say "git only"), and if the underlying SCM says it
has a local version, we append just "+", so you get a version number
like:
2.6.32-rc3+
IOW, you'd never get 2.6.32-rc0, but you'd get either the complex git
version number (or SVN/hg/whatever), or at least "2.6.31+" with the "+"
showing that it is more than plain 2.6.31.
The "+" could be anything else, of course. The diff is pretty obvious, you
can argue about exactly _what_ you'd like to see as a suffix for "and then
some".
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
Makefile | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
Index: linux/Makefile
===================================================================
--- linux.orig/Makefile
+++ linux/Makefile
@@ -963,16 +963,21 @@ localver = $(subst $(space),, $(string)
# .scmversion is used when generating rpm packages so we do not loose
# the version information from the SCM when we do the build of the kernel
# from the copied source
-ifdef CONFIG_LOCALVERSION_AUTO
-
ifeq ($(wildcard .scmversion),)
_localver-auto = $(shell $(CONFIG_SHELL) \
- $(srctree)/scripts/setlocalversion $(srctree))
+ $(srctree)/scripts/setlocalversion $(srctree) | sed 's/^-/+/')
else
_localver-auto = $(shell cat .scmversion 2> /dev/null)
endif
+ifdef CONFIG_LOCALVERSION_AUTO
localver-auto = $(LOCALVERSION)$(_localver-auto)
+else
+ ifeq ($_localver-auto,)
+ localver-auto = $(LOCALVERSION)
+ else
+ localver-auto = $(LOCALVERSION)+
+ endif
endif
localver-full = $(localver)$(localver-auto)
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch] kbuild: Improve version string logic
2009-10-06 17:35 ` [patch] kbuild: Improve version string logic Ingo Molnar
@ 2009-10-06 18:37 ` Johannes Berg
2009-10-06 18:49 ` Ingo Molnar
` (2 more replies)
2009-10-07 2:43 ` David Rientjes
1 sibling, 3 replies; 20+ messages in thread
From: Johannes Berg @ 2009-10-06 18:37 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Dirk Hohndel, Len Brown, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 935 bytes --]
On Tue, 2009-10-06 at 19:35 +0200, Ingo Molnar wrote:
> It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
> way:
>
> - if it is set, things work the way they always have, and you get a
> extended kernel release like:
>
> 2.6.32-rc3+00052-g0eca52a-dirty
>
> ( with the difference that the extra version string is separated via
> '+' not via '-'. This improves visibility when we have additional
> changes over a vanilla tag. )
I really don't see how it improves visibility (unless you're oblivious
to the difference between long and short strings), but I do know that I
have a few parsers that this will break.
I think adding the + unconditionally will also break things like
debian's make-kpkg, for instance, since the + would get propagated into
the package version which reserves the + for something else.
Etc. Can we please make this stuff optional?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch] kbuild: Improve version string logic
2009-10-06 18:37 ` Johannes Berg
@ 2009-10-06 18:49 ` Ingo Molnar
2009-10-06 18:55 ` Johannes Berg
2009-10-06 19:03 ` Theodore Tso
2009-10-06 19:45 ` Frans Pop
2 siblings, 1 reply; 20+ messages in thread
From: Ingo Molnar @ 2009-10-06 18:49 UTC (permalink / raw)
To: Johannes Berg
Cc: Linus Torvalds, Dirk Hohndel, Len Brown, Linux Kernel Mailing List
* Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2009-10-06 at 19:35 +0200, Ingo Molnar wrote:
>
> > It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
> > way:
> >
> > - if it is set, things work the way they always have, and you get a
> > extended kernel release like:
> >
> > 2.6.32-rc3+00052-g0eca52a-dirty
> >
> > ( with the difference that the extra version string is separated via
> > '+' not via '-'. This improves visibility when we have additional
> > changes over a vanilla tag. )
>
> I really don't see how it improves visibility (unless you're oblivious
> to the difference between long and short strings), but I do know that
> I have a few parsers that this will break.
It improves visibility the same way the + at the end of the short
version improves visibility.
That said, i'm perfectly fine with just having the short version include
the '+' sign (i.e. Linus's original patch), that was my original
suggestion and that is already a big step forward.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch] kbuild: Improve version string logic
2009-10-06 18:49 ` Ingo Molnar
@ 2009-10-06 18:55 ` Johannes Berg
0 siblings, 0 replies; 20+ messages in thread
From: Johannes Berg @ 2009-10-06 18:55 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Dirk Hohndel, Len Brown, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 392 bytes --]
On Tue, 2009-10-06 at 20:49 +0200, Ingo Molnar wrote:
> That said, i'm perfectly fine with just having the short version include
> the '+' sign (i.e. Linus's original patch), that was my original
> suggestion and that is already a big step forward.
However, that still breaks current make-kpkg iirc. I haven't used it in
quite some time, so I don't particularly care.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch] kbuild: Improve version string logic
2009-10-06 18:37 ` Johannes Berg
2009-10-06 18:49 ` Ingo Molnar
@ 2009-10-06 19:03 ` Theodore Tso
2009-10-06 19:45 ` Frans Pop
2 siblings, 0 replies; 20+ messages in thread
From: Theodore Tso @ 2009-10-06 19:03 UTC (permalink / raw)
To: Johannes Berg
Cc: Ingo Molnar, Linus Torvalds, Dirk Hohndel, Len Brown,
Linux Kernel Mailing List
On Tue, Oct 06, 2009 at 08:37:07PM +0200, Johannes Berg wrote:
>
> I really don't see how it improves visibility (unless you're oblivious
> to the difference between long and short strings), but I do know that I
> have a few parsers that this will break.
>
> I think adding the + unconditionally will also break things like
> debian's make-kpkg, for instance, since the + would get propagated into
> the package version which reserves the + for something else.
>
> Etc. Can we please make this stuff optional?
That's exactly what I'm afraid of. I'd really like to keep the long
version AUTOVERSION strings the same, please.
- Ted
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch] kbuild: Improve version string logic
2009-10-06 18:37 ` Johannes Berg
2009-10-06 18:49 ` Ingo Molnar
2009-10-06 19:03 ` Theodore Tso
@ 2009-10-06 19:45 ` Frans Pop
2009-10-06 19:48 ` Johannes Berg
2 siblings, 1 reply; 20+ messages in thread
From: Frans Pop @ 2009-10-06 19:45 UTC (permalink / raw)
To: Johannes Berg; +Cc: mingo, torvalds, hohndel, lenb, linux-kernel
Johannes Berg wrote:
> I think adding the + unconditionally will also break things like
> debian's make-kpkg, for instance, since the + would get propagated into
> the package version which reserves the + for something else.
Are you sure? AFAIK it would be propagated into the package _name_, where
it is allowed. And even if it were part of the package version, it would
be in the "upstream" part of the version number, where it is also allowed.
The only reserved use of "+" I'm aware of is in the Debian part of the
package version.
But I have not used make-kpkg in ages, so I'm not 100% sure how that builds
the package version. I could be that it duplicates the kernel version in
both the package name and the upstream part of the package version, but
that should still be OK.
Cheers,
FJP
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch] kbuild: Improve version string logic
2009-10-06 19:45 ` Frans Pop
@ 2009-10-06 19:48 ` Johannes Berg
2009-10-06 20:25 ` Frans Pop
0 siblings, 1 reply; 20+ messages in thread
From: Johannes Berg @ 2009-10-06 19:48 UTC (permalink / raw)
To: Frans Pop; +Cc: mingo, torvalds, hohndel, lenb, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]
On Tue, 2009-10-06 at 21:45 +0200, Frans Pop wrote:
> Johannes Berg wrote:
> > I think adding the + unconditionally will also break things like
> > debian's make-kpkg, for instance, since the + would get propagated into
> > the package version which reserves the + for something else.
>
> Are you sure?
No, I'm not.
> AFAIK it would be propagated into the package _name_, where
> it is allowed. And even if it were part of the package version, it would
> be in the "upstream" part of the version number, where it is also allowed.
>
> The only reserved use of "+" I'm aware of is in the Debian part of the
> package version.
>
> But I have not used make-kpkg in ages, so I'm not 100% sure how that builds
> the package version. I could be that it duplicates the kernel version in
> both the package name and the upstream part of the package version, but
> that should still be OK.
That may all well be true. I wasn't even aware of the distinction
between debian and upstream part of the version :)
I do, however, remember no end to trouble with autoversion and make-kpkg
so eventually gave up on using it entirely.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch] kbuild: Improve version string logic
2009-10-06 19:48 ` Johannes Berg
@ 2009-10-06 20:25 ` Frans Pop
0 siblings, 0 replies; 20+ messages in thread
From: Frans Pop @ 2009-10-06 20:25 UTC (permalink / raw)
To: Johannes Berg; +Cc: mingo, torvalds, hohndel, lenb, linux-kernel
This is a bit OT, but one last reply.
On Tuesday 06 October 2009, Johannes Berg wrote:
> > AFAIK it would be propagated into the package _name_, where
> > it is allowed. And even if it were part of the package version, it
> > would be in the "upstream" part of the version number, where it is
> > also allowed.
>
> That may all well be true. I wasn't even aware of the distinction
> between debian and upstream part of the version :)
The Debian part is everything after the last dash in a package version.
> I do, however, remember no end to trouble with autoversion and make-kpkg
> so eventually gave up on using it entirely.
Yes, problems with autoversion and make-kpkg I can understand as it makes
the revision ID part of the package name, which is very simply not where
you want it [1].
I stopped using make-kpkg for 2 reasons. First of all it is insanely
complex. And second it used to always do a 'make clean' for every build,
which meant a huge inefficiency during bisections and builds after minor
changes; I understand that has been fixed though.
I was happy to discover the kernel's native deb-pkg target. There've been
some improvements to that in recent kernels that make it quite powerful
and flexible for building custom kernels as Debian packages.
Cheers,
FJP
[1] The deb-pkg target does the same, so autoversion is not usable with
that either. What I do is manipulate the output of 'git describe' to set
an ENVVAR that gets used as package version.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [patch] kbuild: Improve version string logic
2009-10-06 17:35 ` [patch] kbuild: Improve version string logic Ingo Molnar
2009-10-06 18:37 ` Johannes Berg
@ 2009-10-07 2:43 ` David Rientjes
1 sibling, 0 replies; 20+ messages in thread
From: David Rientjes @ 2009-10-07 2:43 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Dirk Hohndel, Len Brown, Linux Kernel Mailing List
On Tue, 6 Oct 2009, Ingo Molnar wrote:
> Subject: kbuild: Improve version string logic
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Tue, 6 Oct 2009 09:31:03 -0700 (PDT)
>
> It changes how CONFIG_LOCALVERSION_AUTO works, in the following trivial
> way:
>
> - if it is set, things work the way they always have, and you get a
> extended kernel release like:
>
> 2.6.32-rc3+00052-g0eca52a-dirty
>
> ( with the difference that the extra version string is separated via
> '+' not via '-'. This improves visibility when we have additional
> changes over a vanilla tag. )
>
s/changes/commits/, we'd have to look at the -dirty suffix for uncommited
changes.
The '+' doesn't necessarily always mean there are additional changes since
scripts/setlocalversion will return -00000-EXTRAVERSION when we're at a
release. So when CONFIG_LOCALVERSION_AUTO is enabled, this patch would,
for example, create the version 2.6.32-rc3+00000-rc3.
Perhaps we should suppress setlocalversion's output if git describe
doesn't have a 7-character trailing hash prefixed with 'g'?
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2010-01-18 15:53 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-01-04 21:31 [patch] kbuild: improve version string logic David Rientjes
2010-01-05 13:59 ` Michal Marek
2010-01-05 14:11 ` Stephen Rothwell
2010-01-13 21:01 ` David Rientjes
2010-01-16 6:37 ` Ingo Molnar
2010-01-16 7:34 ` Stephen Rothwell
2010-01-16 9:26 ` Ingo Molnar
2010-01-18 9:40 ` Michal Marek
2010-01-18 10:45 ` David Rientjes
2010-01-18 11:15 ` Michal Marek
2010-01-18 15:53 ` Jiri Kosina
-- strict thread matches above, loose matches on Subject: below --
2009-10-05 0:44 Linux 2.6.32-rc3 Linus Torvalds
2009-10-06 1:57 ` Len Brown
2009-10-06 2:51 ` Dirk Hohndel
2009-10-06 14:18 ` Linus Torvalds
2009-10-06 14:44 ` Ingo Molnar
2009-10-06 15:24 ` Linus Torvalds
2009-10-06 15:36 ` Ingo Molnar
2009-10-06 15:51 ` Linus Torvalds
2009-10-06 16:31 ` Linus Torvalds
2009-10-06 17:35 ` [patch] kbuild: Improve version string logic Ingo Molnar
2009-10-06 18:37 ` Johannes Berg
2009-10-06 18:49 ` Ingo Molnar
2009-10-06 18:55 ` Johannes Berg
2009-10-06 19:03 ` Theodore Tso
2009-10-06 19:45 ` Frans Pop
2009-10-06 19:48 ` Johannes Berg
2009-10-06 20:25 ` Frans Pop
2009-10-07 2:43 ` David Rientjes
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).