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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
