Re: [PATCH, 3.7-rc7, RESEND] fs: revert commit bbdd6808 to fallocateUAPI

[Dave Chinner]

On Sun, Nov 25, 2012 at 09:55:20PM -0500, Theodore Ts'o wrote:
> On Mon, Nov 26, 2012 at 11:28:14AM +1100, Dave Chinner wrote:
> > fs: revert commit bbdd6808 to fallocate UAPI
> > 
> > From: Dave Chinner <dchinner@xxxxxxxxxx>
> > 
> > Commit bbdd6808 ("fs: reserve fallocate flag codepoint") changes the
> > fallocate(2) syscall interface. The flag that is reserved by this
> > commit is for functionality that has previously been NAKed on the
> > -fsdevel mailing list, and so exists out-of-tree.
> 
> Hi Linus,
> 
> It doesn't change the interface or break anything; it just reserves a
> bit so that out-of-tree patches don't collide with future allocations.
> There are significant usages of this bit within Google and Tao Bao.
> It is true that there has been significant pushback about adding this
> functionality on linux-fsdevel;

It's not the fact that you want to reserve a bit that is at issue
here - it's the way it's been pushed into the tree that is the
front-and-center issue.

> I find it personally frustrating that
> in effect, if enough people scream, they can veto an optional feature
> that might only be implemented by a single file system.

Having a significant portion of the wider fs development community
disagree with your patches is no reason for subverting the review
process.  Besides, that's irrelevant to the issue being discussed,
unless you are describing your motives in an effort to justify your
actions.

In fact, it's even more disturbing if this was your real motive.
That is, is sounds somewhat like you've just admitted that you
pushed this change silently through the ext4 tree to avoid review
and discussion and that you are blaming the rest of the FS community
for forcing you to take such actions.

> It's not like there is any shortage of flag bits, so what's the harm
> of reserving the bit?

The harm has already been done - to the trust we've placed in you as
a maintainer.  To argue that the code does no harm is to completely
miss the crux of the issue at hand: principles, process and trust
are far more important in our community than a single line of
code.

Ted, it comes down to trust. If we can't trust you not to push your
own changes to syscall APIs into the mainline tree via backdoor
channels, then how can we trust you not to push the entire
out-of-tree patch into the kernel the same way?

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/