Re: FMODE_EXEC or alike?

[Christoph Hellwig]

On Wed, Feb 22, 2006 at 04:42:02PM -0500, J. Bruce Fields wrote:
> On Wed, Feb 22, 2006 at 08:59:00AM +0000, Steven Whitehouse wrote:
> > Hi,
> > 
> > Also GFS2 (which we hope to be ready to submit to the kernel shortly)
> > would want to make use of this feature. Its been a long standing entry
> > on our TODO list,
> 
> So there's a question here about ordering of these sorts of patches.
> 
> At CITI we've done some work on making nfsd play nicely with cluster
> filesystems (e.g., to allow consistent locking across NFS clients
> talking to different NFS servers exporting the same cluster filesystem).
> 
> The work is partly motivated by (and so far only tested with)
> out-of-tree filesystems.  We've had some minor discussion with GFS2 and
> OCFS2 hackers but assumed there was no use asking for serious review
> until there was an in-tree filesystem that could take advantage of them.
> (So we're happy to hear GFS2 is nearly ready--OCFS2 isn't attempting
> cluster-coherent locking at all for now.)
> 
> Should we be pushing these sorts of patches earlier, at least as long as
> they're fairly low-impact?  Or should we be observing an absolute rule
> against introducing new interfaces without also introducing in-tree
> users?

That patch adds lots of unused code so far now a clear NACK.  Even after
users are in mainline such additions would need a clear justification.
Can for example some existing locking code be removed?  fs/locks.c is
a huge mess right now and adding more and more entry points doesn't
exactly help there.

Oh, and given that's it's stuff deeply interwinded with the file locking
code it should become _GPL exports.

-
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/