linux-kernel - Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate UAPI

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

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

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

Message-Id: <201212061037.56597.Martin@lichtvoll.de>
Date:	Thu, 6 Dec 2012 10:37:56 +0100
From:	Martin Steigerwald <Martin@...htvoll.de>
To:	linux-kernel@...r.kernel.org
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Chinner <david@...morbit.com>,
	"Theodore Ts'o" <tytso@....edu>,
	"linux-fsdevel" <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocate UAPI

Am Donnerstag, 6. Dezember 2012 schrieb Linus Torvalds:
> On Wed, Dec 5, 2012 at 5:14 PM, Dave Chinner <david@...morbit.com> 
wrote:
> > And for changes to syscalls? That's something that must be peer
> > reviewed because we are going to be stuck with those changes forever
> > as we can't undo them at a later date. It doesn't matter who made the
> > change in question, I would have done exactly the same thing....
> 
> The thing that people are complaining about is exactly the reverse of
> this. It's *protecting* us from making mistakes, and doesn't actually
> add any new interfaces in itself.
>
> This is why I'm so annoyed with this stupid thread. It's been going on
> forever, and reverting that change WOULD BE OBJECTIVELY A BAD IDEA.

See, thats where you have a problem with "reality".

It seems you cannot accept the fact that some developers disliked the 
process in which this change was pushed. It seems to be that you want this 
thread to vanish in thin air immediately. But unfortunately it didn´t.

So while the process generally is fluid, I agree to that, it wasn´t fluid 
here. Or would you call this fluid here?

I accept the fact that a decision has been made. And I am not deeply 
enough into the technical matters to have to continue discussing it. I 
also think all arguments have been said.

The process has been the way it is. Noted. For the future there is 
potential to do it differently with less churn involved. Will you, Ted and 
others involved take the chance? Up to you entirely. And depending on what 
effect you want to create.

BTW: I do not buy into your tough guy number. Scare someone else with 
that, if it makes you feel better about yourself. So thanks for the 
factual stuff that you delivered after your first post to the thread.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
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/