linux-kernel - Re: [GIT PULL] tracing/urgent for v2.6.31

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

Hash Suite for Android: free password hash cracker in your pocket

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

Message-ID: <alpine.LFD.2.01.0906102002260.6847@localhost.localdomain>
Date:	Wed, 10 Jun 2009 20:18:40 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frédéric Weisbecker <fweisbec@...il.com>
Subject: Re: [GIT PULL] tracing/urgent for v2.6.31

On Thu, 11 Jun 2009, Ingo Molnar wrote:
>
> Let me know if we should instead avoid the conflict by backmerging 
> tracing/urgent more frequently.

No. So far, the merges from -tip this time around have been a pleasure.  
And I'd _much_ rather get a few conflicts, if that means that we can keep 
the things more separate, and have a more readable history. I think I had 
a total of two conflicts, and both of them were totally trivial.

[ Famous last words. Maybe I screwed them up. Whatever. They were simple 
  enough that even if I _did_ screw them up, it won't be anything serious ]

The only one that could have been better (modulo bugs or other 
misfeatures, of course - let's see how this merge window turns out) is the 
tracing one, which I really wish could have been split up more. That was a 
big half-meg diff, which meant that unlike the other ones, I couldn't 
really scan through it and feel like I got a feel for it. 

Aside from that one not being as obvious as the others, no big issues at 
least so far.

The only (small) complaint is that some new things seem to default to 'y', 
which I'm dubious about, but having several different and independent git 
trees, with small enough diffs that I can actually look at them, and with 
a history that is clearly "one area", makes it just _soo_ much easier for 
me to merge.

As to config options - why in the world does something like X86_PTRACE_BTS 
have a 'default y'? Yes, it got disabled again with a 'depends on BROKEN', 
but on the whole, that whole thing seems crazy. And I'm not talking about 
the code, I'm talking about whoever decided that it should have that 
strange 'default y' thing.

New features should _never_ default to 'y'.

I think defaulting CONFIG_FTRACE to 'y' is dubious too, but at least 
that's not a new feature as much as a new config option making other 
config options visible. But again, I do think it should likely default to 
off, even so.

Similarly, CONFIG_MARKERS seems to be forced to 'y' by something. Why?

Anyway - apart from small details like that, so far so good. If tracing is 
going to get this much churn in the future, I do wish that in the future 
different tracers be split up. But the merges have been way more readable 
this time. Good job.

		Linus

PS. Ok, I also do hate the prefix "ds". It tells nothing. There's a lot of 
new global functions etc that have that prefix. Sure, if you read the 
intel debug documentation, the whole "debug store" thing makes sense, but 
I think prefixes like that should be longer and more telling.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/