Re: [PATCH] fs: Restore files_lock and set_fs_root exports

[Ingo Molnar <mingo@elte.hu>]

* Christoph Hellwig <hch@infradead.org> wrote:

> > What's under discussion here is "how to do it".  Do we just remove things
> > when we notice them, or do we give (say) 12 months notice?
> 
> Remove when we notice with a short (measured in weeks) period where
> that removal happens only in -mm.  It's a price people have to pay for
> not submitting their code upstream.

let me chime in as the author/maintainer of Tux, which is an out-of-tree
patch that relies on VFS internals. VFS changes constantly break Tux in
one way or another, but i've not complained once because:

   _I simply have no right to complain_

either i submit the code and then i can expect it to be taken into
account, or i dont. It's _the_ basic quid pro quo that keeps technology
moving towards mainline Linux. So if i have to fix up Tux (both for
exports and for other internal details), then that's the price. Often i
have to change Tux to do things differently - and in most cases it's Tux
that was doing things incorrectly. And note that Tux is not a
binary-only module, it's a fully GPL patch.

does this cause more work for me? Sure. Would i prefer to have less
work? Yes, but not in such a shortsighted way. Tux staying external is a
choice i made and i also care about Linux and i very much like the way
the VFS is evolving.

so my strong position is that even asking for any 'warning period' for
changes in VFS internals (including exports/unexports) would be
extremely rude. It would be rude not only towards the authors and
maintainers of mainline VFS code, but also towards other external
trees/drivers who do _not_ ask for any special status and accept the
deal: "follow internals, notice kernel people if they do bad stuff
(extremely rare in my case) and fix/redesign stuff if the external tree
is broken (much more common)".

	Ingo