Ingo Molnar wrote:
if the infrastructure your are advocating does not allow us to keep the
existing output then it's simply not flexible enough.
Let's be precise. If "keep the existing output" means any format change is
unacceptible to you, then I broke things. If it means that my method provides
data equivalent in respect of content, then I didn't break the lock contention
output.
Why on earth are you even arguing about this?
> A "cleanup" should not change the output, simple as that.
> Do a patch that has the _same_ output and then we can
see whether it's a good patch. You made the same mistake with your
/proc/timer_stats cleanups.
We got to be careful here. My other proposal was doomed because timerstat became
kernel ABI in the meantime. We won't break the kernel ABI. I was late, as simple
as that.
The lock contention stuff isn't kernel ABI yet. This is -mm code, stuff
intented for a wider audience and discussion. It should be perfectly fine
to scrutinize kernel ABI additions before we get beyond the point of no return.
I dont like NACK-ing patches but you seem to
be missing the basic precondition of cleanups: no functional effect to
the code, and certainly no change in output.
I don't see the point of judging something by goals that have not been set.
I have advertised my patches as: same purpose, different or generalised method,
differences in output format, output equivalent in respect of content,
much more code sharing.
Martin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
