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

[Dave Chinner]

On Thu, Dec 06, 2012 at 11:50:24AM -0500, Theodore Ts'o wrote:
> On Thu, Dec 06, 2012 at 07:06:45AM -0500, Christoph Hellwig wrote:
> > 
> > Also the only conference outcome I remember is that everyone at LSF
> > except for Ted basically said "no fucking way".
> > 
> 
> At LSF, that's correct.  And as a result, the people who need this --
> Google and Tao Bao -- have decided to keep the patch as an out-of-tree
> patch, much like the Android wakelock patch was out of tree, and for
> similar reasons --- because the community has rejected the
> functionality.

Sure. But your association argument can be shown to be a fallacy
very easily.  There was agreement that wakelock-like functionality
was needed, the problems were with the proposed implementation and
that everyone would work together on a solution. Hence the mainline
kernel now has integrated wakelock support.

Compare that to stale-no-hide: the -concept- was given a fairly
unanimous "not a chance in hell" send-off. There was no "lets rework
it into something acceptable" compromise - the concept was
rejected and so you simply cannot compare it to wakelocks.

> At this point, I've only asked that the bit be reserved, so we don't

Really? We wouldn't be having this discussion if you'd just asked...

> have to worry about codepoint collisions.  (We'd have the same issue
> with an ioctl, BTW --- we would need to reserve an ioctl number to
> avoid collisions, although granted there are ways to cleverly choose
> an ioctl number that would reduce the chance of collisions even if it
> isn't formally reserved.)

struct ext4_ioc_falloc {
...
};

/* security hole reserved for out-of-tree patches. */
#define EXT4_IOC_FALLOC_NOHIDE		_IOW('f', 10000, struct ext4_ioc_falloc)

Done. Not so hard, is it?

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/