.. let's see how much, if anything, breaks due to the version number.
Probably less than during the 3.0 timeframe, but I can just imagine
somebody checking for meaningful versions.
Because the people have spoken, and while most of it was complete
gibberish, numbers don't lie. People preferred 4.0, and 4.0 it shall
be. Unless somebody can come up with a good argument against it.
So far, the arguments against it seem to have been "major numebr
should go with a major new feature or breaking of compatibility",
which just shows how little people know. We don't break compatibility,
and we haven't done feature-based releases since basically forever.
On the other hand, the strongest argument for some people advocating
4.0 seems to have been a wish to see 4.1.15 - because "that was the
version of Linux skynet used for the T-800 terminator".
So on the whole, I wouldn't read too much into the number.
On an actual technical side, this was a *fairly* small release. By
modern standards, that is. It's certainly noticeably smaller than some
recent kernels have been, although we're talking ~9k non-merge commits
rather than 10-11k, so it's not like it's that huge of a difference.
The live patching infrastructure made some news, but my personal
favorite features are actually some vm cleanups, where this release is
getting rid of the largely unused non-linear remapping code (replaced
with just emulating it with lots of smaller mappings) and unifies the
NUMA and PROTNONE handling for page tables.
But nobody should notice. Because moving to 4.0 does *not* mean that
we somehow changed what people see. It's all just more of the same,
just with smaller numbers so that I can do releases without having to
take off my socks again.
Go test it out. The git trees are already out, the tar-ball and
patches are going out as I write this. Of course, with the version
change, I suspect that there will be *some* hiccup with kernel.org
mirroring, even if Konstantin thinks that the scripts are all ready to
go.. So if you don't find tar-balls and patches, either I screwed up,
or Konstantin did ;)
Linus
Hi all,
As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)
I haven't done these for a while, so I haven't included a previous
release for comparison.
(No merge commits counted, next-20150209 was the last linux-next before
the merge window opened.)
Commits in v4.0-rc1 (relative to v3.19): 8950
Commits in next-20140804: 8279
Commits with the same SHA1: 7492
Commits with the same patch_id: 452 (1)
Commits with the same subject line: 70 (1)
(1) not counting those in the lines above.
So commits in -rc1 that were in next-20150209: 8014 89.5%
Some breakdown of the list of extra commits (relative to next-20150209)
in -rc1:
Top ten first word of commit summary:
103 mips
79 staging
37 drm
32 lguest
25 ib
22 arm
19 rdma
19 input
19 alsa
18 sunrpc
Top ten authors:
51 [email protected]
50 [email protected]
25 [email protected]
21 [email protected]
19 [email protected]
17 [email protected]
16 [email protected]
15 [email protected]
15 [email protected]
14 [email protected]
Top ten commiters:
81 [email protected]
75 [email protected]
64 [email protected]
59 [email protected]
47 [email protected]
43 [email protected]
38 [email protected]
31 [email protected]
26 [email protected]
26 [email protected]
There are also 265 commits in next-20150209 that didn't make it into
v4.0-rc1.
Top ten first word of commit summary:
25 rcu
24 arm
20 selftests
19 mm
11 arm-soc
6 documentation
5 tracing
5 staging
5 libceph
5 ceph
Top ten authors:
36 [email protected]
34 [email protected]
20 [email protected]
11 [email protected]
9 [email protected]
7 [email protected]
6 [email protected]
6 [email protected]
5 [email protected]
4 [email protected]
Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those).
Top ten commiters:
102 [email protected]
35 [email protected]
21 [email protected]
11 [email protected]
10 [email protected]
9 [email protected]
7 [email protected]
7 [email protected]
7 [email protected]
4 [email protected]
Those commits by me are from the quilt series (mainly Andrew's mmotm
tree).
--
Cheers,
Stephen Rothwell [email protected]
Hi Linus,
On Mon, Feb 23, 2015 at 4:06 AM, Linus Torvalds
<[email protected]> wrote:
> Because the people have spoken, and while most of it was complete
> gibberish, numbers don't lie. People preferred 4.0, and 4.0 it shall
> be. Unless somebody can come up with a good argument against it.
Thanks for the release we've all been waiting for!
But are you sure it's 4.0-rc1? The tag says "Linux 34.0-rc1" ;-)
$ git show v4.0-rc1
tag v4.0-rc1
Tagger: Linus Torvalds <[email protected]>
Date: Sun Feb 22 18:32:41 2015 -0800
Linux 34.0-rc1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJU6pFJAAoJEHm+PkMAQRiG2OwH/24nDK+l9zkaRs0xJsVh+qiW
8A2N1od0ickz43iMk48jfeWGkFOkd4izyvan/daJshJOE1Y5lCdSs7jq/OXVOv9L
G0+KQUoC5NL0hqYKn1XJPFluNQ1yqMvrDwQt99grDGzruNGBbwHuBhAQmgzpj1nU
do8KrGjr7ft1Rzm4mOAdET/ExWiF+mRSJSxxOv598HbsIRdM5wgn0hHjPlqDxmLN
KH4r3YYEm0cHyjf4Krse0+YdhqdamRGJlmYxJgEsYNwCoMwkmHlLTc71diseUhrg
r/VYIYQvpAA6Yvgw8rJ0N5gk/sJJig+WyyPhfQuc2bD5sbL9eO7mPnz2UP7z7ss=
=vXB6
-----END PGP SIGNATURE-----
...
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tag/?id=v4.0-rc1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Mon, Feb 23, 2015 at 6:15 AM, Stephen Rothwell <[email protected]> wrote:
> Hi all,
>
> As usual, the executive friendly graph is at
> http://neuling.org/linux-next-size.html :-)
>
> I haven't done these for a while, so I haven't included a previous
> release for comparison.
>
> (No merge commits counted, next-20150209 was the last linux-next before
> the merge window opened.)
>
> Commits in v4.0-rc1 (relative to v3.19): 8950
> Commits in next-20140804: 8279
[ CC Thorsten Leemhuis ]
Hi Stephen,
thank you for a statistical overview.
It should be interesting and document the Linux-next development.
Especially what came in from last -next release (release before
v4.0-rc1) into v4.0-rc1 - as you write this was next-20150209.
Is that a typo next-20*14*0804?
How did you generate your statistcs (number of commits, top-ten, etc.)?
Thorsten is doing a fantastic job by explaining what is going on in
the Linux-kernel development in his "Kernel-Log" [1] article series
(German). On the last page he describes how he extracted the "numbers"
(please see [2]).
May have a look at it?
Personally, I don't like any of Linus' -rc1 release announcement (but
I read them).
What are the pearls - what is "worth mentioning" - what new stuff is
worth testing (scripts/diffconfig last-stable-config
latest-rc1-config)?
As someone interested in Linux-kernel I expect to get these
informations more "user-friendly".
( IMO, It is irresponsible that user walk through all commits or
merge-commits. )
As a conclusion:
I am interested in such statistics and thank you for this email.
Thanks.
Regards,
- Sedat -
[1] http://www.heise.de/open/kernel-log-3007.html
[2] http://www.heise.de/open/artikel/Die-Neuerungen-von-Linux-3-19-2541595.html?artikelseite=3
> Commits with the same SHA1: 7492
> Commits with the same patch_id: 452 (1)
> Commits with the same subject line: 70 (1)
>
> (1) not counting those in the lines above.
>
> So commits in -rc1 that were in next-20150209: 8014 89.5%
>
> Some breakdown of the list of extra commits (relative to next-20150209)
> in -rc1:
>
> Top ten first word of commit summary:
>
> 103 mips
> 79 staging
> 37 drm
> 32 lguest
> 25 ib
> 22 arm
> 19 rdma
> 19 input
> 19 alsa
> 18 sunrpc
>
> Top ten authors:
>
> 51 [email protected]
> 50 [email protected]
> 25 [email protected]
> 21 [email protected]
> 19 [email protected]
> 17 [email protected]
> 16 [email protected]
> 15 [email protected]
> 15 [email protected]
> 14 [email protected]
>
> Top ten commiters:
>
> 81 [email protected]
> 75 [email protected]
> 64 [email protected]
> 59 [email protected]
> 47 [email protected]
> 43 [email protected]
> 38 [email protected]
> 31 [email protected]
> 26 [email protected]
> 26 [email protected]
>
> There are also 265 commits in next-20150209 that didn't make it into
> v4.0-rc1.
>
> Top ten first word of commit summary:
>
> 25 rcu
> 24 arm
> 20 selftests
> 19 mm
> 11 arm-soc
> 6 documentation
> 5 tracing
> 5 staging
> 5 libceph
> 5 ceph
>
> Top ten authors:
>
> 36 [email protected]
> 34 [email protected]
> 20 [email protected]
> 11 [email protected]
> 9 [email protected]
> 7 [email protected]
> 6 [email protected]
> 6 [email protected]
> 5 [email protected]
> 4 [email protected]
>
> Some of Andrew's patches are fixes for other patches in his tree (and
> have been merged into those).
>
> Top ten commiters:
>
> 102 [email protected]
> 35 [email protected]
> 21 [email protected]
> 11 [email protected]
> 10 [email protected]
> 9 [email protected]
> 7 [email protected]
> 7 [email protected]
> 7 [email protected]
> 4 [email protected]
>
> Those commits by me are from the quilt series (mainly Andrew's mmotm
> tree).
>
> --
> Cheers,
> Stephen Rothwell [email protected]
On 02/23/15 04:06, Linus Torvalds wrote:
> On the other hand, the strongest argument for some people advocating
> 4.0 seems to have been a wish to see 4.1.15 - because "that was the
> version of Linux skynet used for the T-800 terminator".
So they have changed our future already as we will likely hit 4.1.15 way
before 2029 ;-p
Regards,
Arend
On Mon, 23 Feb 2015, Arend van Spriel wrote:
> On 02/23/15 04:06, Linus Torvalds wrote:
> > On the other hand, the strongest argument for some people advocating
> > 4.0 seems to have been a wish to see 4.1.15 - because "that was the
> > version of Linux skynet used for the T-800 terminator".
>
> So they have changed our future already as we will likely hit 4.1.15 way
> before 2029 ;-p
Using 15 year obsolete software versions is not that uncommon for
embedded and military ;)
c'ya
sven-haegar
--
Three may keep a secret, if two of them are dead.
- Ben F.
Am 23.02.2015 um 04:06 schrieb Linus Torvalds:
> .. let's see how much, if anything, breaks due to the version number.
> Probably less than during the 3.0 timeframe, but I can just imagine
> somebody checking for meaningful versions.
>
> Because the people have spoken, and while most of it was complete
> gibberish, numbers don't lie. People preferred 4.0, and 4.0 it shall
> be. Unless somebody can come up with a good argument against it.
The only argument that I can come up with is "we do not break userspace".
For example there is this "gem" in configure.ac of valgrind:
case "${kernel}" in
2.6.*|3.*)
AC_MSG_RESULT([2.6.x/3.x family (${kernel})])
AC_DEFINE([KERNEL_2_6], 1, [Define to 1 if you're using Linux 2.6.x or Linux 3.x])
;;
2.4.*)
AC_MSG_RESULT([2.4 family (${kernel})])
AC_DEFINE([KERNEL_2_4], 1, [Define to 1 if you're using Linux 2.4.x])
;;
*)
AC_MSG_RESULT([unsupported (${kernel})])
AC_MSG_ERROR([Valgrind works on kernels 2.4, 2.6])
;;
esac
This seems to be historic and unused now in the code base. I will send a
patch to valgrind-devel, that just gets rid of this check, but the check
is in all released versions of valgrind and probably others. I think
we do not care that much about failures when building valgrind on top of
systems running 2.2. If we do, I can certainly add a specific check for
1.*,2.0,2.1,2.2,2.3 that bails out then.
Christian
Hi,
On Sun, Feb 22, 2015 at 9:15 PM, Stephen Rothwell <[email protected]> wrote:
> There are also 265 commits in next-20150209 that didn't make it into
> v4.0-rc1.
>
> Top ten first word of commit summary:
>
> 25 rcu
> 24 arm
> 20 selftests
> 19 mm
> 11 arm-soc
> 6 documentation
> 5 tracing
> 5 staging
> 5 libceph
> 5 ceph
>
> Top ten authors:
>
> 36 [email protected]
> 34 [email protected]
> 20 [email protected]
> 11 [email protected]
This is expected. We keep a next-only index file of what merges we've
done in arch/arm/arm-soc-for-next-contents.txt which accounts for
these commits.
-Olof
On Mon, 2015-02-23 at 16:43 +0100, Christian Borntraeger wrote:
> Am 23.02.2015 um 04:06 schrieb Linus Torvalds:
> > .. let's see how much, if anything, breaks due to the version number.
> > Probably less than during the 3.0 timeframe, but I can just imagine
> > somebody checking for meaningful versions.
> >
> > Because the people have spoken, and while most of it was complete
> > gibberish, numbers don't lie. People preferred 4.0, and 4.0 it shall
> > be. Unless somebody can come up with a good argument against it.
>
> The only argument that I can come up with is "we do not break userspace".
> For example there is this "gem" in configure.ac of valgrind:
>
>
> case "${kernel}" in
> 2.6.*|3.*)
> AC_MSG_RESULT([2.6.x/3.x family (${kernel})])
> AC_DEFINE([KERNEL_2_6], 1, [Define to 1 if you're using Linux 2.6.x or Linux 3.x])
> ;;
>
> 2.4.*)
> AC_MSG_RESULT([2.4 family (${kernel})])
> AC_DEFINE([KERNEL_2_4], 1, [Define to 1 if you're using Linux 2.4.x])
> ;;
>
> *)
> AC_MSG_RESULT([unsupported (${kernel})])
> AC_MSG_ERROR([Valgrind works on kernels 2.4, 2.6])
> ;;
Heh, if this is an argument, we have one hell of a lot of reverting to
do :) Crash for example breaks at much higher resolution, and indeed
just broke yet again. Tough titty for userspace methinks.
-Mike
Am 24.02.2015 um 03:34 schrieb Mike Galbraith:
> On Mon, 2015-02-23 at 16:43 +0100, Christian Borntraeger wrote:
>> Am 23.02.2015 um 04:06 schrieb Linus Torvalds:
>>> .. let's see how much, if anything, breaks due to the version number.
>>> Probably less than during the 3.0 timeframe, but I can just imagine
>>> somebody checking for meaningful versions.
>>>
>>> Because the people have spoken, and while most of it was complete
>>> gibberish, numbers don't lie. People preferred 4.0, and 4.0 it shall
>>> be. Unless somebody can come up with a good argument against it.
>>
>> The only argument that I can come up with is "we do not break userspace".
>> For example there is this "gem" in configure.ac of valgrind:
>>
>>
>> case "${kernel}" in
>> 2.6.*|3.*)
>> AC_MSG_RESULT([2.6.x/3.x family (${kernel})])
>> AC_DEFINE([KERNEL_2_6], 1, [Define to 1 if you're using Linux 2.6.x or Linux 3.x])
>> ;;
>>
>> 2.4.*)
>> AC_MSG_RESULT([2.4 family (${kernel})])
>> AC_DEFINE([KERNEL_2_4], 1, [Define to 1 if you're using Linux 2.4.x])
>> ;;
>>
>> *)
>> AC_MSG_RESULT([unsupported (${kernel})])
>> AC_MSG_ERROR([Valgrind works on kernels 2.4, 2.6])
>> ;;
>
>
> Heh, if this is an argument, we have one hell of a lot of reverting to
> do :) Crash for example breaks at much higher resolution, and indeed
> just broke yet again. Tough titty for userspace methinks.
Well crash is not a good example as it by design goes beyond the user ABI
and directly touches the kernel data structures ;-)
I am not requesting to go back to 3.*, I was just pointing out that if we apply
strict rules on "we dont break userspace", the move to 3.* and 4.* was a mistake.
We do provide uname26 as a workaround, so this is ok and the switch to 4 should
be a lot smoother.
But better end the discussion here :-)
Christian
FWIW, valgrind svn is fixed as of yesterday (for good, so Linux 5.* 6.*.. should
also work)
Le 24/02/15 08:40, Christian Borntraeger a écrit :
> Am 24.02.2015 um 03:34 schrieb Mike Galbraith:
>> On Mon, 2015-02-23 at 16:43 +0100, Christian Borntraeger wrote:
>>> Am 23.02.2015 um 04:06 schrieb Linus Torvalds:
>>>> .. let's see how much, if anything, breaks due to the version number.
>>>> Probably less than during the 3.0 timeframe, but I can just imagine
>>>> somebody checking for meaningful versions.
>>>>
>>>> Because the people have spoken, and while most of it was complete
>>>> gibberish, numbers don't lie. People preferred 4.0, and 4.0 it shall
>>>> be. Unless somebody can come up with a good argument against it.
>>>
>>> The only argument that I can come up with is "we do not break userspace".
>>> For example there is this "gem" in configure.ac of valgrind:
>>>
>>>
>>> case "${kernel}" in
>>> 2.6.*|3.*)
>>> AC_MSG_RESULT([2.6.x/3.x family (${kernel})])
>>> AC_DEFINE([KERNEL_2_6], 1, [Define to 1 if you're using Linux 2.6.x or Linux 3.x])
>>> ;;
>>>
>>> 2.4.*)
>>> AC_MSG_RESULT([2.4 family (${kernel})])
>>> AC_DEFINE([KERNEL_2_4], 1, [Define to 1 if you're using Linux 2.4.x])
>>> ;;
>>>
>>> *)
>>> AC_MSG_RESULT([unsupported (${kernel})])
>>> AC_MSG_ERROR([Valgrind works on kernels 2.4, 2.6])
>>> ;;
>>
>>
>> Heh, if this is an argument, we have one hell of a lot of reverting to
>> do :) Crash for example breaks at much higher resolution, and indeed
>> just broke yet again. Tough titty for userspace methinks.
>
> Well crash is not a good example as it by design goes beyond the user ABI
> and directly touches the kernel data structures ;-)
>
> I am not requesting to go back to 3.*, I was just pointing out that if we apply
> strict rules on "we dont break userspace", the move to 3.* and 4.* was a mistake.
> We do provide uname26 as a workaround, so this is ok and the switch to 4 should
> be a lot smoother.
>
> But better end the discussion here :-)
>
> Christian
>
> FWIW, valgrind svn is fixed as of yesterday (for good, so Linux 5.* 6.*.. should
> also work)
>
Changing to v4.0 also seems to be a problem either for genkernel, lvm or
cryptsetup. I use LVM on an encrypted root on gentoo and it doesn't work
anymore. However it works if I rename the kernel to 3.20-rc1.
Does anybody has an idea about that ?
Thanks in advance,
François Valenduc
Le 24/02/15 11:49, François Valenduc a écrit :
> Le 24/02/15 08:40, Christian Borntraeger a écrit :
>> Am 24.02.2015 um 03:34 schrieb Mike Galbraith:
>>> On Mon, 2015-02-23 at 16:43 +0100, Christian Borntraeger wrote:
>>>> Am 23.02.2015 um 04:06 schrieb Linus Torvalds:
>>>>> .. let's see how much, if anything, breaks due to the version number.
>>>>> Probably less than during the 3.0 timeframe, but I can just imagine
>>>>> somebody checking for meaningful versions.
>>>>>
>>>>> Because the people have spoken, and while most of it was complete
>>>>> gibberish, numbers don't lie. People preferred 4.0, and 4.0 it shall
>>>>> be. Unless somebody can come up with a good argument against it.
>>>>
>>>> The only argument that I can come up with is "we do not break userspace".
>>>> For example there is this "gem" in configure.ac of valgrind:
>>>>
>>>>
>>>> case "${kernel}" in
>>>> 2.6.*|3.*)
>>>> AC_MSG_RESULT([2.6.x/3.x family (${kernel})])
>>>> AC_DEFINE([KERNEL_2_6], 1, [Define to 1 if you're using Linux 2.6.x or Linux 3.x])
>>>> ;;
>>>>
>>>> 2.4.*)
>>>> AC_MSG_RESULT([2.4 family (${kernel})])
>>>> AC_DEFINE([KERNEL_2_4], 1, [Define to 1 if you're using Linux 2.4.x])
>>>> ;;
>>>>
>>>> *)
>>>> AC_MSG_RESULT([unsupported (${kernel})])
>>>> AC_MSG_ERROR([Valgrind works on kernels 2.4, 2.6])
>>>> ;;
>>>
>>>
>>> Heh, if this is an argument, we have one hell of a lot of reverting to
>>> do :) Crash for example breaks at much higher resolution, and indeed
>>> just broke yet again. Tough titty for userspace methinks.
>>
>> Well crash is not a good example as it by design goes beyond the user ABI
>> and directly touches the kernel data structures ;-)
>>
>> I am not requesting to go back to 3.*, I was just pointing out that if we apply
>> strict rules on "we dont break userspace", the move to 3.* and 4.* was a mistake.
>> We do provide uname26 as a workaround, so this is ok and the switch to 4 should
>> be a lot smoother.
>>
>> But better end the discussion here :-)
>>
>> Christian
>>
>> FWIW, valgrind svn is fixed as of yesterday (for good, so Linux 5.* 6.*.. should
>> also work)
>>
> Changing to v4.0 also seems to be a problem either for genkernel, lvm or
> cryptsetup. I use LVM on an encrypted root on gentoo and it doesn't work
> anymore. However it works if I rename the kernel to 3.20-rc1.
>
> Does anybody has an idea about that ?
>
> Thanks in advance,
>
> François Valenduc
>
Sorry for the noise, I must have done something wrong. I just tried
again and it worked.
François Valenduc
On Mon, Feb 23, 2015 at 04:15:41PM +1100, Stephen Rothwell wrote:
>
> There are also 265 commits in next-20150209 that didn't make it into
> v4.0-rc1.
>
> Top ten first word of commit summary:
>
> 25 rcu
> 24 arm
> 20 selftests
> 19 mm
> 11 arm-soc
> 6 documentation
> 5 tracing
Yep, that was my tracefs code. It's all ready to go mainline, but then
I did some stress testing on perf, and found that perf hard coded the
mount id into itself, and ignored traceevents if they were not in the
debugfs system (even if the path was the same!). I sent patches to fix
this but because those patches didn't make it into the release, I decide
to not push this knowing it will cause issues with perf.
Thus, tracefs needs to wait till perf is updated before I push it out.
-- Steve
> 5 staging
> 5 libceph
> 5 ceph
>